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Reader Feedback 



Functional verification is a dynamic and fast growing field where verification methodologies 
are continuously enhanced and improved. At the same time, the e language is in the process of 
being adopted as IEEE standard 1647 where its syntactical and semantic features will be sum- 
marized and detailed in a language reference manual. In consideration of these dynamics, this 
book will continue to be updated to reflect the ongoing events in the verification community. 
We encourage you, as the reader, to help enhance this book by sending us your feedback on top- 
ics that you feel should be explained more concisely or more clearly; and we welcome com- 
ments on errors or inconsistencies that we may have overlooked in this first edition. Please send 
us your feedback via E-mail to theehvl@simantis.com. 




Foreword 



I am glad to see this new book on the e language and on verification. I am especially glad to see 
a description of the e Reuse Methodology (eRM). The main goal of verification is, after all, 
finding more bugs quicker using given resources, and verification reuse (module-to-system, 
old-system-to-new-system etc.) is a key enabling component. 

This book offers a fresh approach in teaching the e hardware verification language within 
the context of coverage driven verification methodology. I hope it will help the reader under- 
stand the many important and interesting topics surrounding hardware verification. 

Yoav Hollander 

Founder and CTO, Verisity Inc. 




Preface 



This book provides a detailed coverage of the e hardware verification language (HVL), 
state of the art verification methodologies, and the use of e HVL as a facilitating verification 
tool in implementing a state of the art verification environment. It includes comprehensive 
descriptions of the new concepts introduced by the e language, e language syntax, and its asso- 
ciated semantics. This book also describes the architectural views and requirements of verifica- 
tion environments (randomly generated environments, coverage driven verification 
environments, etc.), verification blocks in the architectural views (i.e. generators, initiators, col- 
lectors, checkers, monitors, coverage definitions, etc.) and their implementations using the e 
HVL. Moreover, the e Reuse Methodology (eRM), the motivation for defining such a guide- 
line, and step-by-step instructions for building an eRM compliant e Verification Component 
(eVC) are also discussed. 

This book is intended for a wide range of users, including junior verification engineers 
looking to learn basic concepts and syntax for their project, to advance users looking to 
enhance the effectiveness and quality of a verification environment, to developers working to 
build eVCs, and also as a reference work for users seeking specific information about a verifi- 
cation concept and its implementation using the e HVL. 
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CHAPTER 1 



Introduction 



1.1 Design of e 

The e hardware verification language is designed to support the special requirements of func- 
tional verification, e provides abstractions that are specifically targeted to better implementa- 
tions of functional verification concepts. Creating a language that provides native support for 
verification concepts gives the following benefits: 

• Less code for engineers to write, which leads to higher productivity when implementing 
a verification environment 

• Less code also means fewer errors in building the verification environment because the 
number of errors in a program is proportional to the lines of code in that program 

• Greater runtime efficiency as verification abstractions are optimized in the language 
runtime engine 

• Provides an easy interface with HDL simulators 

The e programming language was created, supported, and enhanced by Verisity Inc. of 
Mountain View, CA. The Specman Elite® tool suite is also produced byVerisity and provides 
the runtime and development environments for the e language. Specman Elite provides the nec- 
essary utilities for writing, debugging, integrating, reporting, and configuring e programs. 
Although Specman Elite and the e language are closely tied, the e language exists indepen- 
dently of this runtime environment. Therefore, this book mainly focuses on verification tasks 
and their implementation using the e language independent of Specman Elite®. The implicit 
assumption is that an e program should be able to run in any runtime environment developed 
for the language and should not depend on specific implementations of any runtime environ- 
ment. Consequently, this book does not describe Specman Elite in any detail. 
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As of this writing, e is in the process of standardization as IEEE P1647. The goal of this 
standardization process is to develop a standard verification language based on the e language, 
by clearly specifying: 

• The e language constructs 

• The e language interaction with standard simulation languages of interest 

• The libraries currently used in conjunction withe 

• New features of interest 

Once this process is completed, the language grammar and a language reference manual 
will be produced by the working group for this standard. The latest status of this standardiza- 
tion effort can be obtained by visiting www.ieee1647.org. 



1.2 Learning e 



Programming languages are not the end but a means to more efficient implementations of con- 
cepts. We learn a new programming language not because we find new language constructs and 
syntaxes fascinating, but because they are useful in making us become better problem solvers. 
Thus, the first step in learning a new language is to understand the underlying concepts that 
first motivated the development of that language. These concepts are rooted in the problem that 
a language was created to addresses as well as the methodology that is the approach of choice 
for solving such problems as a conceptual level. 

Functional verification is the specific problem e is designed to address. Methodologies for 
performing functional verification have evolved over the years in order to meet the verification 
demands of increasingly complex systems. Detailed understanding of the latest functional veri- 
fication methodologies is essential to learning the e language. 

Before a methodology can be implemented in a programming language, it has to be repre- 
sented with an architectural view. This architectural view consists of components, modules, and 
tasks that have direct correspondence to constructs and abstractions provided in that language. 

This book describes the evolution of functional verification methodologies culminating in 
the development of coverage driven verification methodology (chapter 2). The architectural 
view for effective application of this methodology and its components are described in chapter 
3. As previously stated, in most cases, an architectural view is created with the specific facili- 
ties of a language in mind. In the case of e, language features and facilities were motivated by 
the architecture that leads to the best implementations of coverage driven verification method- 
ology. Before learning the e language, it is important to gain a good understanding of coverage 
driven methodology and the architectural view for its verification environment. Such a detailed 
understanding promotes the learning to become an expert in using e to build a robust and com- 
plete verification environment rather than mere proficiency in the e language. 
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New languages are designed to support new, or a mix of new and existing programming 
paradigms. A programming paradigm describes the view that a programmer has of program 
execution. For example, in object-oriented programming, a program is viewed as a collection 
of communicating objects. In imperative programming, a program is viewed as a state and 
instructions that change this state. Learning how a new language is used is more involved than 
just learning the syntax of that language. A good part of becoming an expert in a programming 
language is understanding how to best implement the solution to a problem using the program- 
ming paradigms supported by that language. Programmers often learn the syntax of a new lan- 
guage only to use this new knowledge to implement a program using concepts from their 
previous programming experiences. For example: for someone already familiar with the 
BASIC programming language, an important step in learning C++ is to learn object-oriented 
programming. It is easy to learn C++ syntax and use it to write a program in the style of 
BASIC. But doing so would defeat the purpose behind the creation of C++ and would render 
learning C++ a futile effort. 

Effective functional verification requires a mix of different programming paradigms, e 
supports imperative, object oriented, aspect oriented, and declarative programming paradigms. 
It is important to learn these programming paradigms and understand the proper use of utilities 
supporting these paradigms. Having a clear understanding of the usefulness of each paradigm 
to each verification task leads to a better verification program that takes full advantage of these 
paradigms. Chapter 4 describes e as a programming language and covers these programming 
paradigms. 

Still, a language cannot be learned completely in a short time. Becoming an expert in a 
new language, its programming paradigms, and appropriate methodologies requires practice, 
and a conscious effort to expand beyond the subset that you know at any given time. The best 
approach to learning e is to focus on the verification tasks and language programming para- 
digms rather than the language constructs. You should start by building the smallest and most 
trivial verification environment on your own. I often come across verification engineers who in 
spite of having one or more years of experience in e, are unable to write the most basic program 
in e simply because their job only required them to learn a subset of the language and to work 
on an already existing program. Learning e is best accomplished by building a skeleton e pro- 
gram for a verification environment, and enhancing the components in this verification envi- 
ronment by learning more about how each component is designed and operated. 

Functional verification has now become a major part of any design project consisting of 
multiple verification developers. Such developers will create code, but often also use code from 
other vendors or previous projects. As such, software programming concepts designed to facil- 
itate code reuse and multiple team development efforts are an important part ofbuilding a veri- 
fication environment. Solid understanding of the e Reuse Methodology (eRM) helps in 
building e verification components that can be reused and combined with components devel- 
oped by other teams. cRM is therefore especially important in working within larger verifica- 
tion environment development projects. 

A systematic approach to learning the e language includes the following steps: 
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• Leam functional verification methodologies especially coverage driven verification. 

• Understand the recommended verification environment architecture for performing 
coverage driven verification. 

• Understand programming paradigms supported by the e language, and their usefulness 
for different verification tasks. 

• Learn eRM to understand how to structure software so that it is reusable and can be 
used combined other independently developed modules. 

• Leam to build the most basic verification environment from scratch, even if all its com- 
ponents have no content. 

• Leam the underlying operation of different language facilities (i.e. random generation, 
temporal expressions, sequences, etc.). Once you know how these facilities work and 
what operations they support, the appropriate syntax can be referenced and remembered 
as you become more familiar with the language. 

• Focus first onjust enough syntax so that you can build a syntactically correct program 
to create the desired module hierarchy and method calls. 



1.3 Programming in e 



Program development consists of 4 main stages: 

• Logistic Planning 

• Analysis 

• Design 

• Implementation 

Logistic planning is concerned with software organization issues such as directory struc- 
ture, naming conventions, future plans for reuse across projects generations, etc. In the analysis 
stage, establish a clear understanding of the problem that needs to be solved. During the design 
stage, key concepts for a solution are identified. During the implementation phase, the solution 
identified in the design stage is implemented in a program. 

Issues discussed in the e Reuse Methodology guidelines (eRM) should be used to plan the 
logistics of a verification project. Issues that must be considered during this phase include: 

• Software Directory Structure 

• Packaging Information and Documentation 

• Naming Conventions 

Use the analysis phase to gain a good understanding of the problem. In the case of func- 
tional verification, the problem is usually solved using one of the verification methodologies 
discussed in chapter 2. Selecting the best methodology, however, depends on the specific 
requirements of the verification task and can be determined by comparing the advantages and 
disadvantages of the different methodologies discussed in this chapter. Given any non-trivial 
verification task, a coverage driven verification methodology is recommended. 
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The design phase corresponds to creating an architectural view of the selected methodol- 
ogy. The architectural view for a verification project is discussed in chapter 3. The implementa- 
tion phase consists of building the modules in the verification environment architecture so that 
the desired behavior is achieved. 

The following general guidelines should be used when building a verification environment 
in the e language: 

• Break up the activities in the verification environment according to the architectural 
representation described in chapter 3. 

• Model verification environment modules using the unit construct. 

• Model the interface between these modules as abstract port definitions using e-Ports. 

• Model abstract data types using the struct construct. 

• Organize the program implementation into two dimensions: modules and aspects. Mod- 
ules define the core implementation of each module. Aspects span modules and define 
properties or functions of these core implementations that can be changed or enhanced. 

• Implement environment modules in the following order: 

• Stimulus Generators 

• Collectors and Monitors 

• Protocol and Data Checking 

• Coverage Collection 

• Follow eRM guidelines for integrating existing e verification components (eVCs) into 
the verification environment. 



1.4 Book Structure 



This book consists of 7 parts: 

• Part I: Describes functional verification methodologies and environment architecture 
independent of any programming language. Topics discussed will be used to motivate 
the features of the e language (chapters 2 and 3). 

• Part II: Introduces e as a programming and verification language. The descriptions in 
these chapters are meant to give reader a comprehensive understanding of features of 
the e language (chapters 4 and 5). 

• Part III: Describes the operation of the constrained random generation utility in e, and 
discusses details of creating the verification environment, stimulus generation, and ver- 
ification scenario generation (chapters 6, 7, and 8). 

• Part IV: Describes the details of temporal expressions and messages, and the architec- 
ture and implementation of monitors, collectors, data checkers, and protocol checkers 
(chapters 9, 10, 11, and 12). 

• Part V: Describes the concepts of coverage collection and issues related to coverage col- 
lection and coverage analysis (chapters 13 and 14). 

• Part VI: Describes the e Reuse Methodology (eRM) and covers in detail the contents of 
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sLutil utility package (chapters 15 and 16). 

• Appendices: Describes the grammar for the e language in the BNF format. Also gives 
the list ofe keywords, and provides checklists for following the eRM guidelines 
(Appendices A, B. and C). 



1.5 Book Conventions and Visual Cues 



The visual cues in this book are shown in the following table. These conventions are used to 
enhance your understanding of the material, e keywords are shown using “times bold” typeset 
to prevent confusion when these terms are included in the main text flow. For example writing 
“the is also extension mechanism can be used’ - leads to ambiguities which are clarified when 
the appropriate keyword typeset is used as shown in the following: “the is also extension mech- 
anism can also be used." 

New terms are indicated with the appropriate typeset wherever a definition for these terms 
are given. By providing a different typeset for new terms, these terms can easily be located and 
their definition found. 



Visual Cue 


Description 


Times 


Book text 


Arial 


e program text 


Arial Bold 


e program text in book descriptive text 


Times Bold 


e keywords 


Times Italic Underlined 


New Terms 



Sample e programs are shown either as e program fragments or as e programs. An e pro- 
gram refers to a code segment that can be compiled by an e compiler as shown in the text. The 
following is an example of an e program: 



1 

2 

3 

4 

5 



extend sys { 
d: uint; 



e Programs are indicated by the solid lines before and after the example body. Code frag- 
ments refer to sample code that cannot be loaded into an e compiler without adding missing 
parts of the program. The following shows an example of a code fragment: 
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1 : struct data { 

2 : payload: uint; 

3 : isjegal: bool; 

4 : }; 



1.6 Summary 



This chapter provided an overview on how this book is best used for learning the e language, 
and how to use e to solve your verification problems. While reading this book, your first focus 
should be on understanding the methodologies and the programming paradigms that makee the 
language of choice for building your verification environment. Your knowledge of syntax will 
grow as you gain more experience in writing verification programs and building verification 
environments. As you learn e, keep in mind that the full power of a programming language is 
unleashed only when used as intended. 
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and Environment Architecture 




chapter 2 Verification 

Methodologies 



In recent years, significant advances in chip and system fabrication technologies have afforded 
designers the ability to implement digital systems with ever increasing complexity. This trend 
has led to a productivity gap between design methodologies and implementation technologies 
where because of this gap, designs produced by existing methodologies do not yield enough 
gates per engineer per month to meet the strict time-to-market deadlines inherent in competitive 
markets. The realization that functional verification now consumes anywhere between 50% to 
70% of the design cycle, has brought functional verification center stage in the effort led by the 
design community to close this productivity gap. 

The focus on functional verification has consisted of a multi-faceted approach where veri- 
fication productivity improvements are made possible through introduction of: 

• New verification methodologies better suited for the verification of complex systems 

• Reusable verification components 

• Hardware Verification languages to facilitate the new verification paradigms 

Verification methodologies and reusable components are abstract concepts that lead to 
verification productivity improvements, while new hardware verification languages are the 
enabling technology for these new concepts. This chapter presents the basics of functional ver- 
ification and suggests metrics for measuring the quality of a verification methodology. It then 
presents the evolution of verification methodologies from task based verification to coverage 
driven constrained random based verification and beyond. The verification metrics introduced 
in this chapter will be used to motivate the introduction of new verification methodologies. 




CHAPTER 2 



2.1 Functional Verification 



The typical design flow and its associated design and verification tasks are shown in figure 2.1. 
All design activity starts from the design specification. The task of a design team is to create a 
hardware implementation through their interpretation of the design specification. This initial 
implementation is translated into the final implementation through a series of steps where 
appropriate design automation tools are used to move from one level of abstraction to the next 
at each step. For example in an ASIC design flow starting at the RT level, the initial RTL imple- 
mentation is created by the design team from the design specification. The RTL implementa- 
tion is then synthesized into a netlist targeting the target implementation technology. This 
netlist is then processed through physical design stages to prepare the final mask information 
used for semiconductor fabrication. 




Figure 2.1 Product Design Flow 



Perhaps the most tedious and error prone step in the design flow is the manual translation 
of the design specification into the initial design implementation. Generally speaking, other 
design tasks are less prone to functional errors because of the high degree of automation 
involved in performing these later steps. The main reasons for functional errors in a design are: 

• Ambiguities in the design specification 

• Misunderstandings by the designer even when the specification is clear 

• Implementation errors even when the implementation goal is clear 

The primary goal of Functional Verification is to verify that the initial design implementa- 
tion is functionally equivalent to the design specification. 
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2.1.1 Black-Box vs. White-Box Verification 

From a functional verification point of view, it is sufficient to verify a design implementation 
by checking its behavior on its boundary (i.e. input and output ports). If a property of a device 
cannot be verified through its ports, then that property is either not controllable (i.e. cannot be 
activated), or not observable. This verification approach is called Black-Box verification. The 
diagram in figure 2.2 shows the verification architecture for performing black-box verification. 
Note that in this approach, a reference model is required to check that the response generated 
by the device is in fact the expected response. 



■N 



Device Under Verification 



Stimulus 



vl 



Design Reference Model 



( 






Figure 2.2 Black-Box Verification 



The features that give a design implementation its performance edge are often not visible 
through device ports. For example, in an instruction accurate CPU verification environment, a 
CPU with an instruction pipeline would functionally seem to behave the same as a CPU with- 
out an instruction pipeline. To verify the correct operation of this instruction pipeline, it is nec- 
essary to examine the design and monitor the instruction pipeline behavior and verify that it is 
providing the performance improvement that the CPU designers intended. In another example, 
consider the settings for FIFO thresholds that are used to trigger FIFO read or write operations. 
Correct operation of such threshold settings would be very hard to verify without visibility into 
the device. Even though it is possible to create a cycle accurate reference model to check for 
such internal behaviors through the device ports, the effort associated with building such an 
accurate model would make black-box verification impractical in most instances. 

Even in cases where a specific feature may be verified through device ports, the difference 
between the time the bug is activated and the time that bug is observed would make any causal- 
ity analyses difficult to track. To enhance debugability, introduce monitors that track internal 
properties with the potential to become sources of device malfunctions. 

White-Box and Gray-Box verification approaches are two alternative approaches that 
overcome limitations of black-box verification. White-Box Verification (figure 2.3) refers to 
verifying a design through checkers (assertion checkers and monitors) without using a refer- 
ence design. Gray- Box Verification (figure 2.3) refers to verifying a design by using a reference 
model but using checkers (assertions checkers and monitors) to improve verification productiv- 
ity. 
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White-box functional verification is usually used for smaller modules in the early stages of 
the design process. This verification approach is hard to reuse and hard to mange. On the other 
hand. Black-box testing is easy to reuse as the verification project moves from module level to 
system level. However, the long latency for detecting bugs, the potential to miss critical internal 
state bugs, and the need to build a detailed reference model make Black-box verification diffi- 
cult to use in practice. Gray-box testing allows the verification engineer to strike the right bal- 
ance between design property checking and building a reference model. Therefore, gray-box 
verification is the approach that provides the most benefit throughout the verification flow. 



2.1.2 Verification Challenges 

As digital devices get more complex and time-to-market requirements become shorter, extra 
pressure is placed on verification engineers to complete exponentially more complex verifica- 
tion projects in shorter time periods. A number of challenges must be addressed in order to deal 
with the increasing complexity of successfully completing a functional verification project. 
These challenges are: 

• Productivity 

• Efficiency 
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• Reusability 

• Completeness 

Verification Productivity is defined as the ability to handle larger designs in a shorter time. 
For design engineers, these productivity gains have been made possible by moving from tran- 
sistor level design to gate level design to RT and system level design methodologies. By 
designing at the RT level, design engineers can plan much larger circuits than if they were 
designing using discrete transistors. The same type of productivity gains must be afforded to 
verification engineers to allow them to deal with increasingly larger devices. Such productivity 
gains are achieved by moving to higher levels of abstraction both in terms of verification utili- 
ties and functional blocks that are being verified. New methodologies taking advantage of such 
new abstractions should be introduced so that the gap between design and verification produc- 
tivity can be bridged. 

Verification Efficiency is a measure of human intervention required to complete a verifica- 
tion task. With the increasing complexity of devices, it is desirable to reduce manual interven- 
tion or manual handling to as little as possible. Verification efficiency is increased by means of 
automation in the verification environment and through introduction of verification tool utili- 
ties, which with appropriate verification methodology, lead to a reduction of manual interven- 
tion. 



Verification Reusability refers to the ability to reuse an existing verification environment, 
or pieces of an existing verification environment for new projects or later generations of the 
same project. Reusability is addressed by developing a modular architecture for the verification 
environment where modules boundaries are identified as pieces that are reuse-candidates in 
new projects. Additional gains can be made through better documentation of the verification 
architecture and the use of software programming and maintenance techniques available that 
simplify code enhancement 

Verification Completeness is the goal to cover as much of the design functionality as pos- 
sible. Improving verification productivity, efficiency, and reusability will provide more time to 
focus on improving verification completeness. It is also possible to further improve complete- 
ness by introducing verification methodologies that focus on this issue and facilities that give 
greater visibility to verification progress. 

Clearly, addressing these challenges effectively is only possible through a comprehensive 
and multi-faceted approach. In short, these verification challenges must be addressed through: 

• New verification methodologies 

• Moving to higher levels of abstraction 

• Using modular design techniques 

• Measuring verification progress 

• Reducing manual effort through automation 

• Improved software development environment 

• Better documentation 

• Using software development techniques 

• New verification language features (utilities) to facilitate these new methodology and 
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software development requirements 

2.1.3 Simulation Based Verification 

The fundamental operation in simulation based verification is the process of device state activa- 
tion followed by device response checking (figure 2.5). In this operation, the device is placed in 
a specific state and correct device response at that state is checked. Note that in this representa- 
tion, a device state may refer to a simple device state as defined by the contents of its registers 
and status of its state machines. A state in this representation may also represent an operating 
mode of the device where the device may go through many simple states while operating in that 
mode. For example, in a state machine, the device state in this diagram may refer to a specific 
state of the state machine, while for a bus interface module, a state may refer to write or read 
operation cycles for the interface module. 



Put device into a Check that device 

specific state / / response is correct 



Figure 2.5 Simulation Based Verification 



All functional verification requirements can be described as a series of such fundamental 
operations. Figure 2.6 shows a conceptual representation of the verification space for a given 
device. This representation describes the relationship between simulation steps in terms of the 
stimulus required to move the device into a given state. 








| B | Bug Revealing State | C-d Comer Case State | G | Goal State 
Figure 2.6 Device Verification Space 



J 



At the beginning of a verification project, the verification team establishes Goal States in 
the verification space that must be reached sometime during the simulation run. The aim of ver- 
ification would be to generate the necessary stimulus to put the device into these goal states. As 
the device moves into new states on its way to the goal state, checkers guarantee the correct 
device response at each step. Because of the abstract definition of a device state where each 
state may also represent a device operating mode, it is possible to define a hierarchical verifica- 
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tion space where at the higher levels, such a diagram describes correct device operation as it 
moves from one mode of operation to another, while at lower levels, such a diagram represents 
correct device operation at the most detailed level. 

Consider a state machine and its corresponding verification space shown in figure 2.7. In 
this representation, each state in the verification space corresponds to a state in the original 
state machine. In addition, the necessary check at each step is that the current state is valid 
based on previous state and the input values, and that the output generated at that state is as 
expected. 




00 




Figure 2.7 FSM Verification Space 



The verification space for a bus interface module, shown in figure 2.8, gives verification 
targets in terms of modes of operation for the bus interface module. 




It should be noted that verification goals often depend not only on reaching a specific 
state, but also on how that verification target is reached. For example, in the finite state machine 
shown in figure 2.7, it is possible to reach state ARM through two different input combinations. 
Measuring verification progress therefore requires that not only target states are considered but 
also how these target states were reached. 
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2.1.4 Verification Terminology 

The verification space as described in the previous section, is used to define the terminology for 
functional verification. 

Each interesting scenario that should be verified is a Verification Scenario (VS). A verifi- 
cation scenario is described in terms of a sequence of verification state traversals in the verifi- 
cation space. A Verification Item is the verification step (i.e. simulation run) that verifies the 
correctness of one or more verification scenarios. This can happen if a simulation run traverses 
a path in the verification space that spans multiple verification scenarios. The collection of ver- 
ification scenarios form the Verification Plan (VP). The Verification Suite is the collection of 
verification items that verifies all scenarios in a verification plan. The design implementation 
that is being verified is the Device Under Verification ( DUV ). The Verification Environment 
(VE) (i.e. Verification Bench ) is the collection of DUV and all verification related constructs. 

In the context of verification environment development. Physical Level refers to signal 
descriptions at the bit and bit vector levels. Physical views are used to describe DUV at the 
hardware level. Logical View refers to any abstracted view in the design or environment. A log- 
ical view of data traffic may correspond to the data frame representation of physical level val- 
ues. A logical view of a DUV may correspond to its user interface at a task level (i.e. write to 
device, read from device). Physical Interface refers to ports that are described at the physical 
level. Logical Interface refers to port interfaces that are described at a logical level. 



2.2 Verification Metrics and Verification Quality 



Verification methodologies are adopted according to their benefit. It is therefore necessary to 
identify a number of metrics that will be used to measure the effectiveness of a verification 
methodology. This section presents a number of verification metrics that will be used through- 
out this chapter to discuss the merits of different verification methodologies. The metrics pre- 
sented in this section are closely related to the verification challenges discussed in section 
2.1.2. Some of these metrics are measured quantitatively while others are used as qualitative 
guidelines for discussing merits of verification methodologies. 

The following metrics are considered in measuring the value of a verification methodol- 
ogy: 

• Granularity 

• Productivity 

• Effectiveness 

• Completeness 

• Reusability of the V erification Environment 

• Reusability of the Simulation Data 

Verification Quality refers to the combination of these verification metrics. 
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2.2.1 Granularity 

Verification Granularity is a qualitative metric used to measure the degree of detail (i.e. granu- 
larity) that should be considered in crafting a verification plan, and subsequently completing 
the verification project. The ultimate goal is to allow verification engineers to deal with verifi- 
cation concepts at the highest level of abstraction possible. It is important to note that in func- 
tional verification, it is ultimately the traffic at the physical level (logic values on device 
signals) that should be verified. In this context, moving to a higher level of abstraction is only 
possible if the handling of the layer hidden under this newly introduced abstraction can be auto- 
mated without loss of any detail at the physical level. 

The move to a higher level of abstraction comes in two forms: 

• Verification Goal Abstraction: 

• Deal with less detailed tasks 

• Higher Level Verification Language Constructs 

• Write less code for same task 

• Make fewer mistakes in developing the environment 

Verification goal abstraction allows the verification engineer to concentrate on higher 
level data constructs instead of logic values on device wires. For example, by providing an eth- 
ernet verification component, a verification engineer can define a verification goal as “injecting 
a valid ethemet packet” instead of having to describe the sequence of activity that will lead to 
such a packet at the device port. In this case, the ethemet verification component handles all the 
detail necessary to inject a valid packet. It is therefore important to pay careful attention to the 
design and usage of verification components used to architect a verification environment. 

More powerful Language constructs allow the verification engineer to implement the 
same task in fewer lines of code and therefore a shorter time. As is commonly known in soft- 
ware development, the number of bugs in a software program is proportional to the number of 
lines of code. Thus, by reducing the verification code size, the potential for errors in verifica- 
tion code is also reduced. 

2.2.2 Productivity 

Verification Productivity is a measure of the amount of manual effort that is involved in a veri- 
fication project. This manual effort consist of: 

• Developing the verification environment 

• Verifying all verification scenarios in the verification plan 

• Maintaining the verification environment 

• Migrating the verification environment for next project 

Maintaining and migrating a verification environment includes measures that should be 
anticipated during the development of the verification environment. The main focus in devel- 
oping a methodology for improving productivity is to minimize the amount of manual effort 
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required to develop the environment and create the set of items that verify all scenarios in the 
verification plan. 

As in most engineering tasks, there is a fine balance between the effort spent on environ- 
ment development and the effort required to create the set of all necessary verification items 
(verification suite). The more time is spent on development, the less time spent on creating the 
verification suite, and vice vera. For example, if the verification environment is complex 
enough to handle all comer cases automatically, then the manual effort required to test corner 
cases is very small. In general, considering all possible corner cases in a verification environ- 
ment can be very time consuming and it is often best to verify such extreme corner cases 
through manually created verification items. The remainder of this chapter provides methodol- 
ogy guidelines that help in striking the right balance between these two efforts. 



2.2.3 Effectiveness 

During simulations runs, the goal is to verify all the scenarios described in the verification plan. 
Verification Effectiveness provides a measure for the contribution of a simulation run to the 
overall task of verifying all the scenarios in the verification plan. Ideally, all time spent in run- 
ning any simulation should improve verification plan coverage. 



2.2.4 Completeness 

Verification Completeness is a measure of the portion of device function verified during the 
course of the verification project. Generally, no verification plan can completely specify all fea- 
tures and all possible corner cases. Although it is relatively easy to define a measure of com- 
pleteness for a verification plan (i.e. measure how many scenarios have been covered), it is 
difficult to measure completeness when referring to all possible features of a design. 

Since completing all verification scenarios in a verification plan is a required goal for the 
verification project, then verification completeness is concerned with the part of device func- 
tion that may not be specified explicitly in a verification plan but is indirectly verified during 
the verification project. 

In a verification environment where each scenario is explicitly verified (i.e. directed veri- 
fication), completeness of device verification is hardly extended beyond the verification plan 
scenarios. However, in a verification methodology where verification scenarios are randomly 
generated and device response is automatically checked, it is highly likely that many scenarios 
beyond the initial verification plan are also verified. 



2.2.5 Verification Environment Reusability 

Verification Environment Reusability may be defined in two ways: 

♦ Reusing verification environment for next generations of the same design 
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• Reusing verification environment modules and utilities while moving from module 
level verification to system level verification 

The main assumption in re-using a verification environment across design generations is 
that design generations have similar profiles and features, though slightly modified or 
enhanced. The main challenge in achieving this target is to anticipate future design changes and 
to identify modules and features that are expected to change. By defining clear architectural 
boundaries between pieces that are expected to change and the pieces that are expected to 
remain the same, the environment migration tasks can be drastically reduced. 

Reusing the verification environment through the project life-cycle is a more pressing 
requirement for projects where turnaround time is very important. As verification tasks move 
from module level verification to system level verification, verification is less focused on gen- 
eration and more attention is placed on collection, monitoring, and coverage collection. A gen- 
eral guideline for achieving this target is to architect the verification environment such that the 
required pieces for system level verification (monitors, checkers, coverage collectors) can func- 
tion independently from the generators. 



2.2.6 Simulation Result Reusability 

Simulation Results refers to the data that is collected during simulation runtime. It is often the 
case that after a long simulation run is completed, either the need to check some additional 
properties is realized, or it would be useful to find out if a certain scenario was in fact exercised 
during the simulation run. At one extreme, if a signal change dump of all signals during the 
simulation run is available, all such questions can be answered by analyzing the simulation data 
dump. At another extreme, if no data is stored, then the entire simulation has to be rerun for any 
question to be answered. The right approach is obviously to strike a good balance between the 
amount of collected data and the types of questions that may need to be answered after a simu- 
lation run is completed. Simulation Result Reusability refers to the ability to selectively define 
the information collected during simulation run so that post-simulation analysis can be per- 
formed without having to re-run the simulation. 

Consider a multiplier design that multiplies two 16 bit numbers. If we collect a list of all 
pairs of numbers that have been multiplied during simulation, we can answer any question on 
whether the multiplier has been tested for a given pair of numbers without having to rerun the 
simulation. Not only is it is important to collect the numbers seen on each input port, but the 
correlation between these input values should also be recorded. 

Data reusability is usually considered as part of coverage collection strategy. During cov- 
erage collection, it is very important to collect information on specific coverage questions, and 
also to anticipate future questions that may arise and if possible, collect the necessary data to 
answer such questions without having to rerun the simulation. 
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2.3 Directed Test Based Verification 



Directed Test based verification is a brute force technique for completing a verification project. 
In this approach, a specific verification item is created for each verification scenario and new 
facilities are implemented, or the existing infrastructure is enhanced to support the require- 
ments for each new verification scenario. 

The one and only potential advantage of a directed test based verification methodology is 
that project progress is almost linearly proportional to the amount of time spent on the project 
(figure 2.9). In this approach, verification progress is made one time-consuming and small step 
at a time. A directed test based verification methodology may be recommended for a verifica- 
tion environment that lacks modern verification tools and languages, or for projects where very 
little time is available to complete the verification phase and therefore insufficient time is 
devoted to target full verification. Studying directed test based verification is useful for two rea- 
sons: first, the need for more advanced verification methodologies is motivated by studying the 
shortcomings of this approach. Second, a directed test based approach may be used as part of 
other verification methodologies to cover very hard to reach corner case verification require- 
ments. 




The fundamental steps in directed test based verification are very simplistic. These steps 
are: 

• Complete the verification plan 

• Sort the scenarios in the verification plan according to some priority considerations 

• For each scenario, enhance the existing environment, or build new infrastructure to ver- 
ify that specific scenario 

• Add the completed verification item to the verification suite for regression 
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The sorting of verification scenarios in this approach may depend on multiple factors, 
including the importance of the features that are verified, the natural order of verification code 
development as the verification environment is being enhanced, and the order of development 
for the device under verification. 

2.3.1 Task Driven Verification Methodology 

Directed test based verification in its most fundamental form interacts with the DUV using 
physical level signals. This low level interaction and modeling introduces major inefficiencies 
in building the verification environment and verifying scenarios. Task Driven Verification 
Methodology is a variant of the directed test based verification methodology where logical 
views are used to improve verification productivity (figure 2.10). In task driven verification 
methodology: 

• Traffic is defined at a higher level of abstraction (frames, packets, instructions etc. ). 

• Verification tasks are defined at a logical level (write to port, read from port, issue 
instruction, etc.) 

• Verification utilities are developed to support these new data structure and task defini- 
tions 

• Verification scenarios are created one scenario at a time using the available verification 
utilities 
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Figure 2.10 Task Driven Verification Methodology 



2.3.2 Verification Quality 

The brute nature of directed test based verification leads to significant loss of productivity. In 
such cases, the most fundamental shortcoming is that each verification scenario has to be con- 
sidered independently and human interaction is required to set up the verification environment, 
generating the necessary traffic, and checking results for each verification scenario. At the 
same time, the verification plan may describe scenarios using ranges of acceptable values for 
each parameter. Using a directed test based approach, the values for these parameters have to be 
specifically decided, and often, additional scenarios created for corner cases consist of specific 
combinations of such parameters. The main problem with this approach is that it is difficult and 
time consuming to enumerate values for different parameters and come up with comer case 
conditions. 
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Additionally, because of the amount of hard-coded values in a directed test based 
approach, such a verification environment is hard to maintain and not easily portable even 
across very similar projects. 

To summarize, the advantages of task driven verification methodology are: 

• Improves productivity over the most basic task driven verification methodology by 
introducing tasks and abstract data types 

• Useful as part of a more comprehensive verification methodology to cover very specific 
comer cases 

The disadvantages, however, include: 

• Requiring human interaction to create and check each scenario, leading to very low pro- 
ductivity 

• Requiring detailed enumeration of all scenarios and corner cases (often too numerous to 
be possible) leading to verification incompleteness 

• Difficult to use, tedious to maintain, and impossible to port across projects because of 
extreme customization of each verification item 

Random generation of data and scenarios is used to improve on the shortcomings of task 
driven verification methodology. This verification methodology in described in the next sec- 
tion. 



2.4 Constrained Random Test Based Verification 



Randomization is a powerful technique, which, when used appropriately, can drastically 
improve verification quality. A closer look at the anatomy of a verification scenario can lead to 
a better understanding of the way randomization is leveraged to improve verification quality. 

A verification scenario describes a well defined order of low level transactions in the veri- 
fication environment where a set of data and parameter values are associated with each low 
level transaction . Ideally, a set of atomic transactions can be defined where any verification 
scenario is composed of a sequence of these atomic tr ansactions. Each atomic transaction will 
require a set of data and parameter objects to complete its activity. Obviously, not all sequences 
of such atomic transactions lead to meaningful scenarios. At the same time, not all possible data 
and parameter combinations are allowed for a given atomic transaction. The legality of valid 
data and parameters may depend on the context (i.e. order of an atomic transaction within a 
sequence). 



1 A parameter modifies the behavior of a transaction while data does not. For example, for a bus read trans- 
action, read burst size is a transaction parameter since it modifies the number of bus cycles, etc., while address 
to read from is considered transaction data since the transaction behavior is generally independent of its value. 
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Assume a list of such atomic transactions and their corresponding valid orderings, valid 
data content, and valid parameter content is available for a DUV. It is then straight forward to 
see that given enough time, all verification scenarios in the verification plan can be created by 
generating random sequences of these atomic transactions along with their corresponding data 
and parameters, while constraining the random generation to the subset of valid sequences, data 
values, and parameter settings. 

Constrained Random Test Based leverages the concept of randomization to automatically 
generate constrained random sequences that by exercising the necessary device functions, ver- 
ify the scenarios in the verification plan. This methodology leads to immediate and significant 
gains in verification productivity and completeness. 

Using this methodology, it is no longer necessary to individually implement and verify 
each scenario in the verification plan (as is the case for directed test based verification) there- 
fore improving verification productivity. At the same time, random generation of scenarios 
leads to far more scenario activations than could possibly be listed in a verification plan. This 
increase in the number of scenarios randomly generated leads to significant improvement in 
verification completeness and greater confidence in design correctness. 

Practical deployment of constrained random based verification requires significant 
changes in verification environment implementation. The most fundamental requirement mov- 
ing from directed test based verification to constrained random based verification is that the 
verification environment should be able to properly handle all types of activity generated by the 
random generation process. In directed test based verification, each scenario is built explicitly 
and the environment’s response to that scenario could also be implemented while verifying the 
specific scenario. For constrained random based verification, any valid sequence of atomic 
transactions ( including the ones that may not be in the verification plan) as well any valid data 
may be generated during simulation therefore the environment has to be implemented to handle 
all such activity. 

Note that the verification environment supporting randomly generated data and scenarios 
should not only support the generation and successful completion of all possible scenarios, but 
also automatically check that correct system behavior was observed at every stage of randomly 
generated scenarios. 

It is clear that since scenarios are generated randomly, verification progress can only be 
measured as each new scenario is generated, and verification progress is not known before sim- 
ulation is run. This is in contrast to directed test based verification where verifying all directed 
tests guarantees complete coverage of the verification plan. This means that the verification 
environment supporting constrained random based generation should also include the neces- 
sary infrastructure to measure verification progress as simulation continues. 

A finite state machine is a design style wherein the benefits of constrained random based 
verification are immediately obvious. In this design style, the verification plan simply consists 
of traversing all possible edges between states. 

• Generator: 
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• Generate Random states constraining the state to the valid set of states 

• Generate Random inputs 

• Checks: 

• Check that the correct next state is reached after each clock cycle 

• Check that correct output is produced while in each state 

♦ Coverage: 

• Collect the set of all states reached 

• Collect the set of all inputs applied while in a given state. 

An important issue to consider is that complete verification of a finite state machine 
requires that the next state value is checked for all possible input combinations. This require- 
ment is not practical, however, for any real size finite state machine description. 



2.4.1 Random Based Verification and Practical Considerations 

Constrained random based verification, in its most ideal application (i.e. state machine testing), 
is very effective in improving the verification quality. But in real designs, a number of consid- 
erations make a fully randomized environment (i.e. verifying all possible device behavior in 
one simulation run) difficult to achieve. These factors include: 

• The extensive effort required to build a verification infrastructure capable of supporting 
all scenarios 

• Extremely low probability of reaching some comer case conditions without very spe- 
cific constraint; even for very long simulation runs 

• Not enough time to wait for eventual verification of all scenarios 

• Randomly repeating the same verification scenario leading to low effectiveness 

Sometimes during verification environment development it becomes clear that adding 
support for a randomly generated comer case condition would require extensive effort. Under 
such conditions it is advisable to build a directed test that verifies that specific comer case con- 
dition. Note that this comer case condition may in fact have its own randomly generated data 
and parameters but the assumption in running such a scenario is that a customized verification 
environment is required for handling that specific scenario. 

Additionally, many parameters exist in a modem DUV and it is practically impossible to 
reach a specific corner case condition by a generic set of random generation constraints. Under 
such conditions, it is advisable to create a specific verification item with very specific con- 
straints on random generation such that comer case condition occurs with very high likelihood. 
At the same time, it is generally the case that different sets of random generation constraints 
will lead to the generation of different groups of verification scenarios. Therefore, it is neces- 
sary to create multiple verification items where each verification item is focused on a group of 
verification scenarios. 

To summarize, a constrained random based verification environment will in practice 
include: 
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• Verification environment infrastructure targeted to specific comer cases that require 
special handling 

• Multiple Verification Items each having random generation constraints that lead to dif- 
ferent types of verification scenarios or very specific comer case conditions. 



2.5 Coverage Driven Verification 



As described in the previous section, constrained random based verification methodology leads 
to significant improvements in verification completeness and productivity. However the poten- 
tial gains promised by this approach may be difficult to harness without a clear strategy for 
measuring verification progress. 

To that end, important questions that must be answered during constrained random based 
verification are: 

• Did constrained random generation reach all verification goals? 

• Did constrained random generation reach any interesting non-goal verification states? 

• How much did each simulation run contribute to completing the verification plan? 

• How should generation constraints be modified for the next simulation run? 

Coverage Driven Verification methodology is the unification of coverage collection and 
constrained random based verification where the results of coverage collection are used to 
answer the above questions in order to guide random based verification methodology to a suc- 
cessful completion. 

Coverage driven verification methodology is based on four fundamental concepts: 

• Raising the level of abstraction for verification tasks 

• Constrained random generation of verification data and scenarios 

• Automatic checking of simulation results 

• Coverage collection to measure verification progress and guide random generation to 
cover missing scenarios 

Verification project life-cycle for coverage driven verification methodology is shown in 
figure 2.11. This project life-cycle is divided into four main phases: 

• Phase 1: Verification Plan Development 

• Phase 2: Verification Infrastructure Implementation 

• Phase 3: Verification Environment Bring-up 

• Phase 4: Constrained Random Verification 

• Phase 5: Comer Case Verification 

In the first phase, the verification plan is developed based on the DUV engineering speci- 
fication and design engineer feedback. The goal should be to make the verification plan as 
complete as possible in this first phase as the implementation of the verification infrastructure 
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will depend on the requirements of the verification plan. The verification plan will be updated 
and extended during the project lifetime, however, to include missing scenarios or add new 
DUV features as the DUV is being completed by the design team. 

In the second phase, the necessary infrastructure for supporting the verification plan is 
implemented. In phase three, some simulation runs using strict generation constraints are made 
to check for correct functionality of this implementation. Even though some verification 
progress is made in this phase, the goal is to complete the infrastructure and check for its cor- 
rect operation. Phases two and three may require a few iteration before phase four is started. 

In phase four, the least amount of constraint is used during random generation in order to 
cover as many verification scenarios as possible in any given simulation run. Results from cov- 
erage collection are used to monitor the effectiveness of each simulation run and to modify gen- 
eration constraints to guide scenario generation towards missing verification scenarios. Each 
verification item corresponding to a simulation run will potentially cover many verification 
scenarios which will be measured by coverage collection facilities. During this phase, succeed- 
ing simulation runs will have stricter generation constraints to guide the generation towards the 
missing the scenarios. Consequently, the contribution to overall verification progress may be 
reduced with new verification runs. 

In the phase five, comer case conditions requiring specific modifications to the verifica- 
tion infrastructure are completed. Ideally, any verification scenario that does not require a cus- 
tomized verification infrastructure should be covered in the fourth phase. Comer case 
conditions covered in this phase will look more like task based verification even though some 
parameters and data values of comer case conditions may be randomly generated. 
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2.5.1 Verification Quality 

Coverage driven verification methodology provides the best quality of all verification 
approaches. Verification granularity is high since concepts from task driven verification are 
used to allow verification engineers to deal with more abstract verification tasks. Using the 
concept of constrained random generation provides very high verification productivity because 
human interaction is neither required for generating nor checking every individual verification 
scenario. Verification effectiveness is high as coverage collection is used to gain confidence in 
usefulness of every simulation run. At the same time, verification completeness is also high 
since coverage collection provides good confidence that all verification scenarios in the verifi- 
cation plan have been covered. Random generation of data and verification scenarios leads to 
covering more verification scenarios than the ones listed in the verification plan. In that regard, 
running a simulation beyond the point where the verification plan is fully covered leads to fur- 
ther confidence that additional scenarios not listed in the verification plan are also covered. 
Additionally, judicious collection of coverage allows for reusing simulation results to answer 
further questions about a simulation run after the run is completed. 



2.6 The Enabling Technology: Hardware 
Verification Languages 



The ability to successfully apply coverage driven verification methodology to a verification 
project depends on the availability of a verification language that supports the requirements for 
such a methodology. A hardware verification language should provide: 

• A software development environment that: 

• provides a powerful debugging interface 

• promotes software development practices (i.e. object oriented programming) 

• Simulation Related Facilities that support: 

• Concurrency 

• HDL Simulator Interface 

• Verification related constructs for: 

• Random generation 

• Automatic checking 

• Coverage collection 



2. 7 Summary 



This chapter introduced functional verification and motivated the need for an effective func- 
tional verification methodology. A set of verification metrics were introduced to provide a 
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means for contrasting and motivating the introduction of new verification methodologies. 
Directed test based verification, constrained random based verification, coverage driven verifi- 
cation, and autonomous verification environments were discussed and the introduction of each 
new methodology was motivated by the verification metrics discussed in this chapter. 

This chapter strongly emphasized that the ever increasing complexity of verifying new 
digital systems can only be managed by increasing productivity; and this increase in productiv- 
ity is only possible through automation, reuse, and by moving to higher levels of abstraction. 
Coverage driven verification provides the best combination of all available approaches for 
achieving a good balance between the effort required to build a verification infrastructure and 
completing the project on time and before the deadline. 

Chapter 3 describes the verification environment architecture that is used for applying 
coverage driven verification. 
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The verification methodologies discussed in chapter 2 present verification metrics and 
approaches that lead to good verification quality. This chapter addresses the verification envi- 
ronment architecture and verification utilities needed to allow the application of the methodolo- 
gies discussed in chapter 2. The discussion in this chapter is independent of any specific tool 
and will illustrate the architectural implementation of the methodologies introduced in chapter 
2 as well as further motivate the requirements and features of a hardware verification language. 

The steps in completing a verification project, at a high level, are: 

• Extract the verification plan from the design specification 

• Build the Verification Environment 

• Perform Verification Activity (i.e. coverage driven verification in figure 2.1 1) 

In a verification project, all activity is guided by and measured against the verification 
plan. The features of the verification environment are guided by the requirements of the verifi- 
cation plan, and the completion of the verification project is also measured against the scenar- 
ios listed in the verification plan. As such careful attention to verification plan development is 
essential. 

This chapter discusses verification plan development and presents the verification envi- 
ronment architecture and components that facilitate the advanced verification methodologies 
discussed in chapter 2. 
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3.1 Verification Plan 



The verification plan is the master document for all verification activity. The building of the 
verification plan is perhaps the most important step in completing functional verification. The 
verification plan is used as a guide to: 

• Architect the verification environment 

• Decide what scenarios to verify 

• Define coverage metrics for measuring verification progress 

Once the verification plan is available, the verification environment architecture is imple- 
mented to facilitate the verification of all scenarios in the verification plan. In addition, cover- 
age metrics directly reflect the portion of the verification scenarios that have been verified. In 
this respect, once the verification plan is available, the quality of verification can be measured 
with respect to the verification plan. 

Building a verification plan is somewhat subjective and requires collective decision mak- 
ing across the design and verification teams. Decisions must be made on what features are 
important to verify and what features can be left out or assumed verified as a consequence of 
other verifications. In other words, building the verification plan is subjective and depends on 
the business and technical requirements of the project. The distinction between creating the 
verification plan and other verification steps makes the verification plan the biggest potential 
pitfall in building a successful product, and can mean the difference between success and fail- 
ure. 



The verification space for a DUV is best described as a set of simulation states and the 
necessary conditions to take the DUV into a given state (figure 5.6). For a finite state machine 
design, this view of the verification space is in direct correlation with the physical implementa- 
tion of the DUV where the view of the verification space is in one-to-one correspondence with 
the state machine description. For a more complex device, each state in this view may corre- 
spond to an operation state of the device for a given verification scenario. 

Given such a verification space for a DUV, a set of simulation Goal States are defined 
such that correct device operation, while reaching all such goal states, verifies correct device 
implementation Given the verification space and its corresponding simulation goals, a Verifica- 
tion Plan is the set of all verification scenarios that verify the correct operation of DUV for 
each goal state. A Verification Scenario in its most generic form describes the cause-and-effect 
sequence of taking the DUV to a desired goal state while automatic checks confirm correct 
device behavior. Using this abstraction, a verification scenario is described by: 

• Goals: Simulation goal to be seen sometime during the simulation 

• Input Sequences: Input sequences to apply to take the DUV to the desired simulation 
goal 

• Checks: Checks to perform in goal state, and while reaching the goal state in order to 
verify correct DUV operation 
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Once simulation goals are defined and the necessary checks for each simulation goal iden- 
tified, the specification of the input sequence naturally follows from the device specification. 
Thus, identifying the relevant simulation goals and the necessary checks are critical tasks in 
developing a verification plan. 

3.1.1 Simulation Goals 

A Simulation Goal defines a goal state to be observed sometime during DUV simulation. The 
simulation goal is defined at a given time instance and may include the following information: 

• Valid and invalid values on key attributes 

• Valid and invalid spatial relationships between key attributes 

Verification progress in general can be measured in terms of the number of goal states 
reached during simulation. This assumption is valid when the verification criteria for a goal 
state is independent of the path that leads to that goal state. However, it is often the case that the 
goal state, as well as the path taken to a goal state, will be significant to the verification sce- 
nario. If verification coverage is to be measured in terms of goal states, then the goal state is 
duplicated for each relevant path leading to that goal state. For example, in figure 3.1, the orig- 
inal verification space has two goal states A and B. For goal state B, it is only important that 
state B is reached, For goal state A, however the path leading to that state is relevant to the veri- 
fication task. The verification space is therefore modified to include two goal states A1 and A2. 
In this new verification space, verification is complete (full verification coverage is achieved) 
when all goal states A1 , A2, and B are reached. 




Figure 3.1 Goal State Duplication 



3.1.2 Verification Views 

Two views must be covered when defining attributes to be included in the definition of a goal 
state: 



• Port-Based view 

• Function-Based view 

A Port-Based Verification View describes the DUV behavior as observed through its inter- 
face ports. This view is an integral part of verification for I/O modules such as memory inter- 
face modules, CPU bus attachment units, and standardized serial and parallel ports (i.e. 



33 





CHAPTER 3 



ethemet, USB, UART, etc.). In this verification view the following items are described in a ver- 
ification item: 

• Attributes defined by pin values 

• Attributes defined by data structures passing through DUV pins 

• Interaction between such attributes 

A Function-Based Verification View describes verification scenarios for internal operation 
of the DUV as described in its specification. Even though a DUV behavior, once in use, is only 
visible through its interface ports, a function-based verification plan is necessary for two 
important reasons. First, most DUVs have special functionality that is intended to improve 
device performance. Examples of such functionality include FIFO threshold specifications, or 
cache coherency protocols in microprocessors. Even if the FIFO thresholds for FIFO 
read/writes are not working as expected, the device will seem to function normally through its 
interface ports. At the same time, even though a CPU’s performance will be severely degraded 
without a memory cache, the bus behavior or CPU program will still function. In such cases 
special attention must be paid to device features that are critical to optimal performance but are 
not immediately visible through its port behavior. A second important consideration is the 
cause-and-effect relationships at DUV ports, which usually takes many cycles to complete, and 
any intermediate problems would be hard to track to its source. Therefore, by verifying the 
internal functional steps to implement port behavior, it is easier to locate the source of any 
problem that may be identified at the device ports. 

Function based verification items should consider: 

• DUV states that implement specific device features 

• Simulation goals that describes such DUV states 

In general it is not possible to verify all DUV features. It is therefore important to set some 
guidelines to assure a comprehensive and efficient verification plan. Some guidelines to 
remember while developing a verification plan are: 

• Break down the verification plan into port-based and function-based parts. 

• Include a simulation goal for each Normative Statement 1 in the function specification 

• Exclude simulation goals that are checked as part of other verification scenarios 



3.1.3 Verification Checks 

Once the verification goals are defined, it is necessary to check that the device reaching that 
state, and at that state is performing as expected. 

In general, a device behavior needs to be checked for two conditions: 

• Device does not produce invalid outputs or behavior on its ports or internal signals 



1 Normative Statements are necessary requirements in a specification in order to properly allow a piece of 
equipment to attach to another piece of equipment. 
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• Device responds appropriately to all valid stimulus on its input ports 

Note that in the context of verification, a valid stimulus is defined as all stimuli that the 
device is expected to handle properly. It is possible that in a higher abstraction, such stimulus 
maybe considered “invalid input,” but if the device specification allows for special handling of 
such higher level protocol "invalid input” then, this special handling is considered part of the 
DUV operation and the input stimulus that activates this functionality is considered valid input 
in the context of DUV verification. For example, an ethemet device is expected to reject mal- 
formed ethemet packets received on its ports. From the perspective of ethemet packets, such 
packets are invalid, but such a malformed packet is still a valid verification input stimulus and 
should be applied as part of the verification effort. 

In building a verification plan, it is important to list clearly all valid and invalid port condi- 
tions that a device is expected to handle properly. As will be described later in this chapter, it is 
this list that dictates the required features of the verification environment from the bus func- 
tional models to the monitors and collectors. 

Checks fall into two categories: Syntax Checks and Timing Checks. Syntax Checks refer 
to checking attributes and signal values on DUV ports and internal signals to verify valid com- 
binations. Timing Checks refer to temporal checks across DUV signals that check correct com- 
pliance with expected timing behavior. 

3.1.4 Debugging and the Verification Plan 

A verification plan is expected to expose potential problems in the DUV. It is important, how- 
ever, to provide a means for tracking a problem to its source quickly. In developing a verifica- 
tion plan, the following considerations should be made to improve debugging features: 

• Define verification items in terms of many small operations, as opposed to identifying 
the verification space in terms of a few simulation goals. 

• For each verification scenario, define checks not only for the goal state, but also for all 
intermediate states that lead to the goal state. 



3.2 Verification Environment Architecture 



Verification tasks move in lockstep with the design effort. Therefore, a verification environ- 
ment architecture should reflect the requirements of the design project phase. Two such phases 
of a verification project are the module level and system level verification phases. Having a 
reusable module level verification environment for system level verification is an important 
consideration when defining a verification environment architecture. This section on verifica- 
tion environment architecture focuses on module level verification. Section 3.3 contrasts sys- 
tem level and module level verification and shows how the relevant parts of a module’s 
verification environment is migrated to its system level verification environment. 
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The architectural view of a module level verification environment is shown in figure 3.2. 
Note that in this view, the attachment of the verification environment is shown for only one 
DUV port. 




The prominent features of this verification architecture are: 

• Device Under Verification (DUV) 

• HDL Top-level 

• Verification Bus Functional Model (VBFM) 

• Generator 

• Collector 

• Monitor 

• Predictor 

• Data Checker 

• Coverage Collector 

In this figure, DUV is the device that is being verified. Top-level HDL creates a layer 
where the DUV is connected to other HDL modules that are necessary for its operation. Clock 
and reset generation modules, if in HDL, are also placed in this layer. 

VBFM is the module that provides an abstract view of the DUV to the verification envi- 
ronment and also contains the necessary features for supporting verification operations. The 
generator creates the necessary stimulus and environment settings to produce the specific sce- 
nario that is to be verified. The monitor checks for properties that should be maintained during 
the simulation runtime. The collector extracts output generated by DUV and forms actual data 
items that are then checked against expected data during data checking phase. The predictor 
acts as the reference model for the DUV and generates the expected results for data checking 
operations. The data checker uses the results of the predictor and the collector to compare 
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expected and actual data values. Throughout the simulation., coverage collectors record infor- 
mation that indicate which scenarios have been verified. 

Note that data checking module connectivity (i.e.collector, predictor. Scoreboard) depends 
on the points at which data checking is performed. Therefore the connectivity shown in figure 
3.2 may change depending on data checking strategy. 

The remainder of this section presents a discussion on issues related to VBFM, generation, 
and checking tasks. 



3.2.1 CPU Verification 

The architecture shown in figure 3.3 is best suited for data communication devices where 
device ports act as ports for data traffic. CPU verification would require additional consider- 
ations. The main goal in verifying a CPU implementation is verifying that the CPU executes 
instructions correctly and that system busses comply with the bus specifications. This means 
that CPUs are usually verified by executing a program that is residing in its memory. In other 
words, the stimulus for CPU verification is the program that resides in memory. Often, such 
programs are self-checking programs where the correct execution of the program is verified by 
checking for specific conditions in CPU registers and memoty locations. Because of this 
approach, the stimulus generation for CPU verification is usually a pre-verification step where 
programs are generated before verification starts. Each assembly program in this case verifies 
one or many scenarios in the verification plan. To complete the verification, each assembly pro- 
gram is loaded into the CPU memory and the simulation is run for that specific program. 




BUS 

Figure 3.3 CPU Verification Environment Architecture 



After a program is loaded into the CPU memory, the CPU verification environment 
becomes a self-contained verification environment. This means that no input is injected and no 
output is collected from the environment 2 . Therefore, monitors are key for a CPU verification 



2 CPUs have additional features such as interrupts that require external stimulus. 
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environment to provide visibility into the state of device operation. The location of these check- 
ers is shown in figure 3.3. 

It is possible to create a CPU verification environment where the CPU instructions are 
dynamically created during the simulation process. In this approach, new instructions are gen- 
erated and returned in response to each memory instruction fetch cycle. The advantage of this 
approach is that the mix of instructions may be modified to guide the verification to cover dif- 
ferent parts of the verification plan. 



3.2.2 Verification Bus Functional Model 

A device uses complex protocols at its ports to communicate with outside devices. Hiding this 
physical level port complexity from the verification environment allows the verification envi- 
ronment to interact with the DUV at a higher level of abstraction. Such abstraction of a physical 
port interface forms a more productive easy to use verification environment. A Bus Functional 
Model (BFM) is a module that provides the verification environment with a logical view of the 
physical bit level activity at the DUV ports. The abstraction provided by a BFM facilitates task 
driven verification methodology (figure 2.10). 

A BFM, in its most basic form, is very similar to a module that would be attached to a 
device port in its final application environment. This means that the goal in building a BFM is 
to duplicate the port functionality of a module that will connect to the DUV, and at the same 
time provide a friendlier user interface to simplify interactions with the DUV. Examples include 
a BFM attached to CPU system bus providing a simplified interface to the complex handshak- 
ing on the bus, and an ethernet BFM that translates an abstract ethernet packet into serial bit 
stream corresponding to ethernet traffic. 

Even though the function of a BFM described above is sufficient for simple checking of 
device behavior, these functions must still be extended to include features needed by verifica- 
tion requirements. Such enhancements depend on the verification plan and the conditions that 
should be generated to cover all verification items. 

A Verification Bus Functional Models should provide: 

• A simplified logical interface for interacting with the device 

• Handling bit level interaction with DUV ports for all allowed modes of DUV port oper- 
ation 

• Means to inject errors that the DUV is expected to handle gracefully 

• Fault tolerant features for graceful recovery from faulty device operation 

• Means to set and query configuration settings 

• Status collection and reporting as related to BFM interaction with the DUV 

A VBFM should be able to generate error conditions as part of its feature set. This is nec- 
essary to make sure the device correctly handles error conditions at its ports. In addition, a 
VBFM should be configurable so that it can accommodate different verification scenarios. A 
VBFM should also not fail (i.e. it should either terminate gracefully or continue to search for 
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next valid activity) when detecting a bug in the device, so that automated simulation runs can 
progress without interruption and continue to look for further errors. 

Two important consideration in building a VBFM are: 

• Feature Set 

• User Interface 

These topics are discussed in later subsections. 

3.2.2.1 BFM Features 

An Arrive VRFM is a VBFM that interacts with the DUV by both applying input and reacting to 
outputs. An active VBFM, in its simplest form, should be able to generate all valid input 
sequences to the DUV and be able to react to all sequences that may be observed on the DUV 
output ports. It should also support handshaking sequence required at the DUV port to commu- 
nicate with the DUV. This specification should be immediately identifiable from the DUV 
functional specification. 

As previously mentioned, VBFM includes additional features beyond the basic function of 
a BFM to facilitate verification operations. The specifics of these additional features is not as 
clear, however, as the specification for the basic functionality of the BFM. As a trivial example, 
assume a DUV port signal is expected to be low for only one clock cycle at a time, and different 
errors are detected by DUV when this signal stays low for two, three, or four clock cycles. One 
approach to adding this feature to the BFM is to define 3 BFM transactions that keep this signal 
low for two, three, or four clock cycles. Generating error conditions would then require a 
request to the BFM by specifying the desired transaction. A different approach would be to 
allow for a parameterized transaction where the number of cycles that this signal is low is 
defined along with the transaction request. This trivial example shows that there are different 
ways of defining the feature set of a BFM that achieve the same effect. Some guidelines to con- 
sider while defining the enhanced set of feature for a BFM are: 

• Analyze verification sequences defined in the verification plan to identify the minimum 
set of BFM features that can be combined in different ways to construct the required 
verification sequences. 

• In creating a logical abstraction, a BFM hides details of its interaction with the DUV 
port (i.e. hides handshaking mechanisms). Identifying the types of errors that should be 
created in this physical interaction as part of the verification requirement. Identifying 
the types of information that should be recorded when errors are observed in this lost 
detail. Add capability to the logical interface to create such errors and to query error sta- 
tus. 

• Choose a parameterized BFM feature over multiple BFM features that are essentially 
the same but different in a way that can be parameterized (i.e. error definition in above 
example). 
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3.2.2.2 VBFM User Interface 

A VBFM should have the following user interface: 

• User Request Interface (types of request and parameters for each request) 

• Configuration interface (set configuration and get configuration) 

• Status Interface (get status) 

• Interrupt Interface (using software events) 

As discussed, a VBFM's feature set should be defined to allow for implementation of all 
verification sequences defined in the verification plan. To that end, the verification sequences 
are divided into a set of actions that define an interaction between the VBFM and the DUV, and 
a set of questions about the result of interactions between the VBFM and the DUV. These 
actions are combined in different ways to construct verification scenarios, and the answer to 
these questions are used in performing checks on successful completion of a verification 
sequence. 

Parameters passed to a VBFM request include user data as well as other information 
required for each type of action. For example a memory write action to a system bus VBFM 
requires address and data value, control information such as burst size, and error information 
indicating if any error should be injected on the bus while performing the write operation. 

Parameters common across multiple requests to VBFM should be defined as configuration 
settings for the VBFM. A configuration interface should be defined to allow for setting and 
querying the status ofVBFM configuration. For example, in a bus write action, the burst size is 
usually the same for consecutive write operations so it can be set as a configuration setting for 
the BFM. However, the error injection feature however is more closely tied to each action 
request and is therefore a parameter that is passed to the BFM with each action request. 

The set of questions that need to be answered by a VBFM are included in the status setting 
of the BFM and a status interface is defined for accessing this information. 

A VBFM should generally be able to provide event information at its user interface, such 
as passing the DUV clocking information to the verification environment. Note that this clock 
maybe generated inside the VBFM and then used in the DUV and the verification environment, 
or it maybe taken from the DUV environment. Regardless, the VBFM should pass such clock- 
ing information to the verification environment as needed by the verification requirements. 
Moreover, an active VBFM may need to indicate to the verification environment it has com- 
pleted its latest interaction with the DUV. An event is used to pass such indications to the veri- 
fication environment. 

General guideline for defining the interface for a VBFM are: 

• Identify all requests to VBFM from the set of actions that must be supported by VBFM 

• Identify the required parameters for each request 

• Define the Configuration Interface as the set of request parameters that do not change 
often across multiple requests 

• Define the Status Interface so that VBFM related questions during checking can be 
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answered 

• Define events that will be useful for interaction with the BFM (i.e. elk, reset, different 
events for different types of activity, etc.) 

Figure 3.4 shows an example user interface for a CPU bus VBFM. 




Figure 3.4 CPU Bus VBFM User Interface 



J 



3.2.3 Verification Scenario Generation 

Generation is the process of creating the necessary stimulus to activate a given verification sce- 
nario. In order to generate a verification scenario, the following items should be considered: 

• Verification Environment Initialization 

• DUV and V erification Environment Configuration 

• Data Generation 

• Sequence of Activities that comprise the Verification Scenario 

3.2.3.1 Verification Environment Initialization 

Verification Environment Initialization refers to all data initialization that takes place before 
simulation starts. Environment initialization includes: 

• Memory pre-loading 

• Setting values to registers in the DUV that can only change before simulation is started 

• Assigning values to DUV pins that can only change before simulation is started 

• Verification environment settings 

3.2.3.2 Verification Environment Configuration 

Verification Environment Configuration refers to setting of all DUV and verification environ- 
ment parameters that can change during simulation runtime. These parameters include: 

• Runtime configurable DUV parameters 

• VBFM configuration parameters as described in section 3.2.2. 
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The goal in setting these parameters is to direct the simulation to a desired verification sce- 
nario. Note that if there is only one verification scenario in a simulation run, then initialization 
and configuration steps can be folded into the same step. However, for a simulation run that 
includes multiple scenarios, configuration can potentially changed to guide the simulation 
toward different scenarios during the simulation runtime. 

3.2.3.3 Data and Scenario Generation 

Generating a verification scenario involves generating the traffic that flows through the DUV 
ports, indicating how this data is treated by the verification environment as it flows through the 
ports, in what order the data is applied, and what configuration changes (DUV, or verification 
environment configuration settings) are required to move the simulation toward the goal verifi- 
cation state. The information the generator needs to produce is divided into two categories: 

• Data information: traffic and how the verification environment treats it 

• Sequence information: how the generated data is used to form a verification scenario 

In a verification context, data is not simply the traffic that flows through DUV ports, but 
also the information that describes how a given data item is handled by the verification environ- 
ment (i.e. injecting errors while sending a packet). Note that information that identifies a given 
verification scenario (i.e. how many packets to send) is not considered as part of data items. In 
a verification context, data items include: 

• Data packets flowing through DUV ports. 

• Information on errors that the generated data should contain. Such errors relate to the 
data abstraction that is being generated (i.e. generate an ethemet packet with checksum 
error). 

• Information on errors to be injected by the VBFM while interacting with DUV to send a 
generated data packet. 

A verification scenario consists of a series of steps in the verification space that directs the 
DUV into a goal state. In this view, generating a verification scenario consists of generating the 
sequence of operations that leads the DUV into the goal state. 

Requirements for generating such a sequence of operations leading to a verification sce- 
nario are: 

• Such sequences should be parameterizable. 

• Simultaneous interaction with different DUV ports is required to create most verifica- 
tion scenarios. Synchronization between multiple sequences at different DUV ports is 
required to facilitate complex verification scenarios 

• Complex verification sequences are usually a combination of less complex verification 
scenarios. Ability to generate sequences that are composed of smaller sequences is 
important in generating complex sequences. 

• Complex verification scenarios require interactions with the DUV where output gener- 
ated by the DUV affects the generated sequence. It should be possible to define a 
sequence of operations that depend on DUV output. 
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To complete the verification, a set of verification sequences is generated where each veri- 
fication sequence covers a set of verification scenarios. The goal is to come up with a set of ver- 
ification sequences that completely covers all verification scenarios in the verification plan. 



3.2.4 Monitors 

Monitors, also known as Protocol Checkers and Protocol Analyzers, verify that the traffic at 
DUV ports or DUV internal signals follow the requirements of the design specification. Moni- 
tors are passive components, which means that they do not interact with theDUV. Instead, they 
only sample DUV signals and check the protocol according to rules that are built into the mon- 
itor. 



Monitors are usually placed at DUV ports or internal signals where device operation is 
defined based on well defined protocols (busses, standard ports, etc.), or where specific proper- 
ties should be maintained (i.e. FIFO operations). Monitors are defined based on a set of proper- 
ties that should be maintained throughout the simulation. Note that monitors do not require a 
reference model as the properties that should be maintained is built into the monitor. 

Protocols are defined as a set of properties for signal attributes of DUV signals. Signal 
Attributes specify the allowed values on a DUV signal or a bus. Protocols define two types of 
properties: 

• Syntax Properties: Description of valid attributes and combinations of valid attributes 
that can appeal' on DUV signals 

• Timing Properties: Description of valid attribute sequences across multiple clock cycles 

Syntax checks are in general easy to make. All that needs to be done for syntax checks are: 

• When to check syntax 

• What are the values allowed at the time and place of checking 

Timing checks are more difficult to because of complex inter-relationships between signal 
values across multiple clock cycles. Steps to define timing checks are: 

• Break down the protocol into a number of timing properties that should be maintained 
throughout the simulation 

• Define simple timing check operations that can be used to implement all timing proper- 
ties. 

• Implement all properties in terms of these basic properties. 

The following example shows basic protocol definition for a memory bus interface and the 
description for its protocol checking module. Example of read and write bus cycles for this 
example are shown in figure 3.5. 

Example: Memory I/O module Interface Monitor: 

Signals are: 

ToMemory: Addr, Size, WriteEnable, ReadEnable 

From Memory: MemReady 
Bidir: Data 
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Figure 3.5 Protocol Checking for CPU Bus Read/Write Cycles 



Device Operation Definition: 
Write: 



• CPU asserts Addr, Size, WriteEnable 

• Memory should assert Mem Ready within 4 clock cycles 

• CPU can de-assert Addr and Size once MemReady is asserted 

• CPU continues to assert WriteEnable during write operation 

• When CPU samples MemReady at asserted value, it provides data in next cycles 

• Memory continues to assert MemReady during write operation 

• At the end of an operation, both CPU and memory de-assert all signals 

Read: 



• CPU asserts Addr, Size, ReadEnable 

• Memory asserts MemReady, and Data [Addr] within 8 clock cycles 

• For next Size clock cycles, memory provides following data values on Data 

• Memory continues to assert MemReady throughout the read operation 

• CPU can de-assert Addr, Size, once MemReady is asserted 
Protocol Checking steps: 

Define a sampling time: 

• Use the clock rising edge common to both CPU and memory 
Define basic events: 



• WriteEnableAsserted:WriteEnable asserted at rising edge of clock 

• ReadEnableAsserted: ReadEnable asserted at rising edge of clock 

• cpuEnableAsserted: one of ReadEnable or WriteEnable asserted 

• MemReady Asserted: MemReady asserted at rising edge of clock 

• AddrChanged: value of Addr changed during the previous clock cycle 

• SizeChanged: value of Size changed during the previous clock cycle 
Define Value Holders: 



SizeValue: Value of Size at time of cpuEnableAsserted 
Monitoring Properties: 

Syntax Checks: 
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• SizeValue is always in [1,2,4] 

Temporal checks: 

• If cpuEnableAsserted, then no AddrChanged or SizeChanged before MemRead- 
yAsserted 

• If readEnableAsserted, then MemReadyAsserted happens within 8 clock cycles 

• If writeEnableAsserted, then MemeReady Asserted happens within 4 clock cycles 

• If cpuEnableAsserted, then no cpuEnableDeasserted until MemReadyAsserted 
and then MemReadyDeasserted 

• If MemReadyAsserted, then no MemReadyDeasserted for Size Value clock 
cycles, followed by MemReadyDeasserted at next clock cycle. 

If these checks are performed during the simulation process and observe all valid scenar- 
ios at this interface, then correct operation of the memory interface is completely verified. Note 
however that verifying the correct operation of the interface does not mean that the memory 
device is working correctly. An important step in checking the function of the memory is to 
check that the data was written and read back correctly from the memory, and that memory con- 
tains the expected data based on the history of write operations performed during the simula- 
tion. Data collecting and checking are discussed in the next sections. 



3.2.5 Data Collector 

Data Collection is the step to extract data from the simulation environment while removing 
handshaking and timing information used to move or manipulate the data in the DUV. For 
example, in a memory write operation, the collected data from the memory bus is the address, 
the data to be written, and the size of this operation. All handshaking and control signal infor- 
mation are removed while collecting such data. 

Data collection can be done as part of the monitor or as part of the BFM. This positioning 
of the collector depends on the following factors: 

• BFMs are needed for module level verification, but not necessarily for system level ver- 
ification. Therefore it is better to place data collectors in the monitor module so that 
they can be used as part of the system level simulation environment. 

• Data collection may be done at the DUV ports or at some internal signals of the DUV. 
For internal signals, then the collector is best implemented within the monitor. For port 
signals, the collector may be a part of the BFM functionality. 

As mentioned before, a data collector extracts data from the environment according to a 
data abstraction level. Case in point: for the memory bus, the collected data is in the form of 
memory transaction operations. The following guidelines can be used to decide the type of 
information that should be extracted by a data collector module: 

• Control timing information is usually a part ofprotocol definition. All such timing 
information that is checked by the monitor can be dropped from collected data. 

• What is the minimum amount of data that should be collected to check for correct data 
movement and manipulation? This decision depends on the data checking strategy. 
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For example, one strategy for verifying correct memory module operation, is to extract all 
write transactions from the bus and update a model of the memory with the data write transac- 
tion. This data model is then used to compute the expected result when a read operation is 
encountered. To follow this strategy, this is the information that should be collected: 

• Transaction Type (read/write) 

• Transaction Address 

• Transaction Size 

• Data values (read/write) 



3.2.6 Data Checking 

Data Checking operation is done to verify that DUV handles and moves data according to its 
specification. At its most accurate level. Data Checking consists of a cycle accurate reference 
model where device output are compared to reference values. 

It is usually not necessary to perform cycle accurate checking since protocol checking 
already verifies cycle accurate behavior of the design. In the majority of cases, transaction level 
checking is sufficient. At the same time, data checking may only be needed across a few DUV 
ports or even between internal signals in the DUV. In such cases, a reference model that 
describes DUV behavior across data checking points is sufficient. A data checking strategy is 
defined by: 

• Ports or internal signals across which data checking is performed (i.e. switch ports, 
internal CPU bus to memory interface) 

• Data abstraction for data movement through these ports 

• How the abstracted data is expected to change and move through DUV (requiring a ref- 
erence model) 

Figure 3.6 shows a pictorial view of data checking environment. Note that in this diagram, 
packet source is not indicated. The components of this architecture are: 




Figure 3.6 Data Checking Architecture 



• Reference Model 

• Collector 

• Scoreboard 
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The reference model need only be as accurate as the type of checking that is being done. 
For example, if the data checking is being done at every cycle, then the reference model has to 
be cycle accurate. Also the reference model only need to describe the DUV behavior across the 
points where data checking is being performed. 

The scoreboard is basically a list that is used to hold the expected data until DUV produces 
the data that will match that specific data item. The reference model is often encapsulated with 
the scoreboard. A scoreboard has the following features: 

• Allow for ordered and unordered matching of data/transactions 

• For ordered matching: 

• Flag skipped expected transactions as error 

• For unordered matching: 

• Flave a time-out feature for unmatched expected transactions 

• Provide for initial ignore of mismatched data (in case of devices that require to sync up 
before operating correctly) 

• Provide end of simulation check to make sure all expected transactions have found a 
match 

The design of the collector should also reflect the abstraction used in comparison. For 
example, if the data is being compared at every cycle, then the collector simply samples signal 
values at every cycle, but if the comparison is done at a higher abstraction, then the collector 
must take the necessary steps to extract the necessary data at that level of abstraction. 

Questions to answer in designing a data checking strategy are: 

• At what abstraction level does the data movement and modification need to be checked? 

• Where is the scoreboard placed (the source and destination of data)? 

• Flow do you handle initial and ending conditions (first match, last match)? 

• Is the order of transactions important in scoreboarding? 

The following examples show the scoreboarding strategy for a memory subsystem. 




Figure 3.7 Memoty Subsystem Scoreboarding 
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Figure 3.7 shows the architecture for verifying the functionality of the memory system 
described in the previous section. This architecture consists of: 

• A reference model: This reference model includes a memory model. The function of 
reference model is: 

• Upon a write transaction, it updates its internal memory content 

• Upon a read transaction, it places a read transaction inside the scoreboard. The 
expected value of the read transaction are extracted from its internal memory 
model. 

• A Monitor: To check that all relevant protocols are correctly followed. 

• A collector: extracts memory transactions from the memory interface. Note that in this 
model, the collector is implemented as part of the monitor. 

Figure 3.8 shows an example where the same memory subsystem is used in a system with 
multiple CPU attachments. The bus fabric, including its arbitration module is now a part of the 
DUV. In this case, the data checking strategy should check that all transactions generated at the 
CPU interfaces do in fact arrive at the memory interface port. For this new data checking 
requirement: 

• No reference model is required since transactions are transferred from CPU interface to 
the memory interface without any modifications. 

• Transactions may arrive in different order than the order they were issued because of 
arbitration in the bus fabric 

• Read and Write transactions are checked for both data and address. 




Figure 3.8 System Bus Scoreboarding 
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3.3 Module Level vs. System Level Verification 



During the design flow, modules are initially designed based on input/output specifications. 
Systems are then constructed by combining these modules where each module port is con- 
nected to ports of other modules. During module design phase, most of the errors are in the 
function of the module. During system level verification, however, the majority of the errors 
are detected in port interfaces and in the communication between modules. 

During module level verification, other modules that drive ports of the module under veri- 
fication are not present. Therefore such stimulus should be generated by the verification envi- 
ronment while monitors and data checkers operate to verify correct functionality of the module. 
During system level verification, all or most of the traffic is generated by system modules and 
the verification environment is mostly responsible for protocol and data checking across mod- 
ule boundaries. It is therefore important to architect a module level verification so that its mon- 
itors and data checkers can easily be migrated to the verification environment of the system 
containing this module. 

Figure 3.9 shows a module level verification environment architecture that is readily reus- 
able during system level verification. In this architecture, the DUV module has one input port 
and one output port. Monitors are attached to these ports to monitor protocols and to collect 
data from these ports. The collected data from the input port is passed to a predictor that will 
predict the expected output on the output port. The expected output produced by the predictor is 
then compared against the data item collected on the output port. In this architecture, input data 
is applied to the input port by the generator. Therefore it is easier from an implementation per- 
spective to simply have the generator pass the input data to the predictor. However, if extra 
effort is made to add a collector to the input port to pass the output of this collector to the pre- 
dictor, then the complete protocol and data checking environment for this module can be reused 
during system level verification. As shown in this figure, during system level verification, even 
though the generator module is replaced by another DUV module, the monitors, predictors, and 
scoreboards are directly reused. 

The configuration shown in figure 3.9 is an ideal case where the DUV module implements 
a simple input/output function. In complex modules, building a scoreboarding strategy that can 
completely function based on a module’s ports requires significant effort. A good strategy for 
defining module level verification environment features is to first decide which features of this 
environment should be reused during system level verification and then build the environment 
so that the features (i.e. monitoring, data checking) are independent of the stimulus generation 
modules. 
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Figure 3.9 Module vs. System Level Verification 



3.4 Summary 



This chapter presented the architecture of a verification environment and outlined important 
issues that need to be considered for verification blocks of this architecture. The structure and 
responsibilities of the generator, the collector, the monitor, and data checking modules were 
introduced and issues related to the design of these components were enumerated. 
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CHAPTER 4 



e as a Programming 
Language 



The e hardware verification language is a high level programming language specifically archi- 
tected for hardware verification projects. The e language is a powerful and productive verifica- 
tion tool not only for its high level programming constructs and features, but also because of its 
suitability for modeling projects. 

Programming languages are identified by the following properties: 

• Programming Paradigm 

• Execution Row 

• Data Model 

• Program Structure 

A detailed understanding of these properties is the key to learning any new language. This 
chapter introduces e as a programming language and focuses on its programming properties. 
The discussion will provide an overview of e and describe the basic language constructs neces- 
sary for a beginner to write an e program. Features of e are covered in detail in chapter 5. Veri- 
fication abstractions and features of the e language are discussed in chapter 3. 



4.1 e Programming Paradigm 



A programming paradigm is a methodology for how software systems are constructed. A pro- 
gramming paradigm provides the programmer with a view of the program execution. A partial 
list of programming paradigms includes: 

♦ Imperative Programming: Traditional view of programming, consisting of a program 
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state (i.e. data variables) and a sequence of instructions that change this program state. 

• Declarative Programming: Describes relationships between data variables in terms of 
fixed rules and produces results during the program runtime using these rules. 

• Object-Oriented Programming: Runtime environment is viewed as a collection of com- 
municating objects, each having data members and methods that operate on its data. 

• Aspect-Oriented Programming : Runtime environment is viewed as potentially having 
different views or aspects that require the core implementation to be modified or 
enhanced based on a specific aspect's requirements. 

High level languages are defined and architected to support one or more of these program- 
ming paradigms, according to their intended application. To support these paradigms, a lan- 
guage provides specific constructs that closely match the imposed view of the preferred 
paradigm. For example, the class construct in C++ is introduced to support the notion of 
object-oriented programming. Note that these programming paradigms are generally not con- 
tradictory concepts and a programming language may use or support multiple programming 
paradigms. For example, C++ is an object-oriented imperative programming language. 

e is an imperative, declarative, object oriented, aspect oriented programming language. 
Imperative and object-oriented programming paradigms are commonly used and extensively 
covered in software programming literature. Declarative and aspect-oriented programming are 
powerful paradigms supported by the e language that can provide great benefits when used 
appropriately. These paradigms are discussed in more details in the following sections. 



4.1.1 Declarative Programming 

Declarative programs view the runtime environment as a collection of data variables and a set 
of fixed rules maintained between these variables. It is the responsibility of the program com- 
piler to use built-in inference rules to declare relationships between variables and use the decla- 
rations to perform operations during program runtime. 

Declarative programming style is used extensively in solving Constraint Satisfaction 
Problems' . Constraint satisfaction problems are used in the random generation feature of e 
when constraint declarations are used to specify relationships between fields that are to be gen- 
erated. The important observation is that these constraint declarations are processed by the e 
compiler and are taken into account during the program runtime every time any of the involved 
data objects are generated. Consider the following e code fragment: 



1 : struct data_pair { 

2 : datal :uint; 

3 : data2: uint; 



Constraint-satisfaction problems are mathematical problems where one must find states or objects in a sys- 
tem that satisfy a number of constraints orcriteria. 
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4 : keep datal > data2; - constraint declaration 

5 : }; 



By specifying the constraint declaration describing the relationship between datal and 
data2 in object data_pair, anytime an object of type data_pair is generated during the program 
runtime, the required relationship between datal and data2 is automatically maintained without 
having to re-specify it again. At the same time, any time datal is generated for an object of type 
data_pair, it is always set to a larger value than that of data2. 

Temporal expressions are another powerful feature of the e language. Temporal expres- 
sions use events to represent functions of events and data variables at different times during 
program execution. It is possible to use a declarative statement to define an event to be a func- 
tion of another event, as shown in the following e code fragment: 



1 : struct event_holder 

2 : event A is @B; - event declaration using a temporal expression 

3 : }; 

I ! 

The result of this declaration is that at anytime during program execution, event A is emit- 
ted when event B is executed. 

Random generation and temporal expressions are discussed later in their corresponding 
sections. However the important point in this discussion is that the declarative approach for 
specifying program properties provides great flexibility in defining program properties that 
should be maintained throughout the program execution. This flexibility will prove specially 
useful for verification tasks. 



4.1.2 Aspect-Oriented Programming 

In programming terminology, a concern is defined as the problem a program is trying to solve. 
Separation of concerns is an important goal in program design where a program is broken up 
into distinct features that overlap as little as possible. The main problem that a program is try- 
ing to solve is called the core concern of that program. An aspect is defined as part of a pro- 
gram function that cross-cuts its core-concerns, therefore violating the separation of concerns 
requirement. 

Another possible view of aspect oriented programming is that every major feature of a 
program is an aspect. A program is then created by weaving these aspects into the implementa- 
tion of that program’s core concern. 
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Consider an ethernet port interface module that provides an internal DMA-based bus inter- 
face for its local interface. In the terminology of software programming, the core concern of 
this module is to provide local bus to ethernet port interface. The core concern can be broken 
into two distinct concerns consisting of the DMA controller and the ethernet Media Access 
Controller (MAC). The separation of concerns is maintained for these two since the operation 
of these two modules are essentially independent and communicate only through their respec- 
tive ports. Reporting and coverage collection are two verification related aspects of this mod- 
ule. Verification status reporting requires that both these modules be enhanced to print 
messages when necessary during simulation runtime, and coverage collection requires that each 
module be enhanced to collect coverage data during the simulation runtime. An aspect that 
relates to the function of these modules may require that the range of supported packet sizes be 
reduced for specific applications in which case, both sub-modules must be modified to reduce 
the range of supported packet sizes. 

In concrete terms, aspect-oriented programming allows for redefining and customizing 
objects representing modules or data, for the specific requirements of their intended usage. In 
this type of programming, a core implementation is created that solves the main problem, mod- 
els the main functionality of a system, or represent a data item. Language constructs that sup- 
port aspect oriented programming are then used to customize this core implementation without 
modifying the original program that models the core implementation. 

Aspect-oriented style of programming is supported extensively in the e language. The def- 
initions for data types, objects, and methods can all be extended after the core implementation 
is completed. This feature of the e language is particularly powerful in a verification project 
where the verification scenario can be viewed as an aspect of the verification environment, 
where the core e program is extended to create the aspect that represents that specific verifica- 
tion scenario. 



4.2 Struct and the Struct Instance Hierarchy 



In e, objects are modeled using the struct construct. Structs may have different types of mem- 
bers including data, events, coverage groups, methods, etc. However, struct members that con- 
tribute to the struct instance hierarchy consist of a single or a list of predefined scalar types, 
user defined scalar types, or user defined object types. For example, a data packet containing a 
payload field of eight bits, a parity bit field, and a list of 4 flag bits is modeled by the following 
e code fragment: 



1 : struct data_payload { 

2 : data: uint(bits:8); 

3 : parity: bit; 
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4 : flag_bits[4]: list of bit; 

5 : }; 



In this example, the struct keyword is used to define the data payload object. A struct 
may also include other previously declared structs as one of its members. To define a data 
packet that includes a data payload object: 



struct data_packet { 

header: uint(bits:4); 
payload: data_payload; 

}; 



The struct instance hierarchy for a struct definition is a tree of struct instances whose 
leaves are scalar types and whose nodes are data objects instantiated in its parent struct. For 
example, the struct hierarchy for the data packet object is shown in figure 4.1. 



O data_packet 



| | Leaf Nodes:Sca!ar Data Types 
O Internal Nodes: Composite Data Types 



header 



payload 



□ parity Hill flag_bits[3:0] 
Figure 4.1 Struct Hierarchy for data_packet 



As with all object oriented programming languages, methods can be defined for a struct. 
For example: 



struct data_payload { 
data: uint(bits:8); 
parity: bit 

set_parity(p: bit) is { 
parity = p; 

}; 
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In e, every struct object has a number of predefined methods. These predefined methods 
are the mechanism used to control the order of execution in the runtime environment, as will be 
shown in section 4.3. 

4.2.1 Data References 

In an e program, Data References are used to access data objects 2 . The usage of references in e 
contrasts with using both pointers and references in programs like C++. Reference accesses 
have multiple advantages over pointer access: 

• Dereference operators are not needed with references, while they have to be used with 
pointers. This leads to cleaner code. 

• The memory location pointed at by a reference is implicitly managed by the program 
and can even change during the program runtime during garbage collection. Therefore 
the programmer does not need to explicitly manage memory addresses. 



4.2.2 global and sys 

All data objects in e reside in the global name space global. It is important to keep this organi- 
zation in mind for a number of reasons. 

global is the root of all name resolution scopes. This means that global is the last scope 
checked for a data reference that is not declared in a local scope (i.e. within a struct, or a 
method body). As a consequence, any declaration made in global can be used in any context in 
an e program, assuming that a local declaration does not hide the declaration at the global level. 

global also contains many data structures that are used by the e runtime environment to 
monitor and control program execution. At times it is useful to peek into these data structures to 
learn about the runtime environment of the program. 

global contains the predefined struct sys 3 . sys plays an important role both in instantiating 
user defined data and also in the order of program execution. All user data should be instanti- 
ated under sys. In that sense, sys is the root of the struct hierarchy containing all user data. 
Although it is possible for the user to instantiate data objects under global, this method in not 
generally recommended because of the special handling of sys during program execution. 

As mentioned, sys is a predefined object and therefore adding user defined data instantia- 
tions to sys is only possible through extension of its base definition. This is only possible 
through an aspect oriented utilities provided in e that allow the definition of structs 4 to be 
changed without modifying the base definition. For example, an instance of data packet, as 



2 In an e program, pointers can be used but only for parameters for method calls. 

3 sys is in fact a unit which is a special form of a struct. Units are described later in this book. 

4 struct is only one of extendible constructs in e. Other extendible language constructs are discussed in sec- 
tion 4.5.4. 
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defined in section 4.2, is added to the struct hierarchy using the following e code fragment. In 
addition, the definition for data payload struct is extended in this example to include the new 
member checksum. 

I 

1 : extend data_packet { 

2 : checksum: uint(bits:8); 

3 : }; 

4 : 

5 : extend sys { 

6 : dp: data_payload; 

7 : 1 ; 



Note that extension to a struct may in fact exist in either the same file or one separate 
from the file containing the original definition, but the final effect after reading all files in the 
compiler is the collective result of all extensions to a struct definition. The global struct hierar- 
chy for the above example is shown in figure 4.2. This figure also shows other members of glo- 
bal struct hierarchy that is created by the e program runtime environment. Only the struct 
hierarchy below sys is shown in expanded form in this figure. 



global 




59 




CHAPTER 4 



4.3 Execution Flow 



The e language is architected for the specific requirements of verification projects. As such, e 
uses a predefined execution flow that is more appropriate for verification tasks. Clear under- 
standing of this flow is essential to learning and programming in e. This section describes the 
execution flow of an e program. 

In most programming languages, program execution starts from a predefined procedure 
call (i.e. main() in C or C++) and follows a path dictated by the user's software program. The 
execution flow in e however, follows a predefined order, which is built into the runtime engine 
that executes an e program. As mentioned earlier, this predefined order of execution is orga- 
nized to fit the requirements of a verification project. 

Verification tasks are generally divided into a number of phases. These phases directly 
reflect the verification requirements of the methodologies used for verifying complex digital 
systems. These phases are broadly divided into: 

• Initialization 

• Pre-Run Generation 

• Simulation Run 

• Post-Run Result Checking 

• Finalization 

Initialization is the beginning phase where the environment is initialized with values that 
define the specific verification behavior for the current simulation. During the generation 
phase, the stimulus and environment settings are generated. Actual design simulation takes 
place during the simulation run phase. During the post-run result checking phase, simulation 
results are checked. During finalization phase, verification activity is summarized and final- 
ized. Note that it is only during simulation runtime that simulation time is advanced. Other ver- 
ification phases are performed in zero simulation time. 

The e runtime environment follows an implicit order of execution that mirrors these verifi- 
cation phases. The implicit execution flow for an e program is shown in figure 4.3. Note that in 
this diagram, simulation time is advanced only in the simulation runtime phase. The notion of 
advancing time is discussed in more detail in section 5.3.1. 



4.3.1 Merging User Code into the Implicit Execution Order 

In an e program, every struct has predefined methods that correspond directly to the implicit 
program execution order. Predefined methods of a struct that relate to this execution order are: 

• init() 

• pre_generate() 

• post_generate() 

• run() 

• checkQ 
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Simulation Runtime 




Figure 4.3 e Program Runtime Phases 

I I 

• finalized) 

Because of its special role in the execution flow, sys has additional predefined methods 
that can be extended. One important predefined sys method is setupO which is called during 
the initialization phase. 

The runtime engine for an e program executes the predefined methods of every stiuct in a 
predefined order. The do_test() pseudo code in figure 4.4 shows this predefined order. Upon 
running an e program, the execution flow follows the order shown in do test(). The user pro- 
gram is merged into the main program execution flow by extending the predefined methods 
marked in figure 4.4 with bold typeset 5 . Method extension will be discussed as part of exten- 
sion mechanisms. 

Note that in the actual implementation of the runtime environment, predefined global 
methods are used to create the flow shown in figure 4.4. In addition to creating this flow, these 
predefined global methods handle environment management tasks. 



4.3.2 Steps to Writing an e Program 

The programming steps required to complete a software program in e are: 

• Design the program using object oriented programming principles 

• Define user defined objects using structs 

• Create user data struct hierarchy by extending sys 



5 The generate() method is the method that assigns random values to scalar struct members. Even though this 
method can in principal be extended, this extension is not recommended. 
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do_test() is { 
sys. setup() ; 
sys.do_generate(); 
sys.do_run(); 
sys.do_check(); 
sys.do finalized; 

}; 


do_run() is { 
me.run(); 

for each member M of me t 
if (M is a list of struct) { 
for i from 0 to M.size() { 
M[i].do run(); 

}; 

} else if (M is composite) { 
M.do runO; 

>: 

); 

}; 


do_generate() is { 
me.InltO; 

me ,pre_generate () ; 

while (more members to generate) { 
M = me.next_member_to_gen(); 
if (M is a list of scalar) { 

generate(M.slze()); 
for i from 0 to M.size() { 
generate(M[i]); 

); 

} else if (M is a list of struct) { 
generate(M.sized); 
for i from 0 to M.size() { 
M[i].do_generateO; 

V 


do_check() is { 
me.check(); 

for each member M of me ( 
if (M is a list of struct) { 
for i from 0 to M.size() { 
M[i].do check(); 

}: 

} else if (M is composite) { 
M.do checkQ; 

}; 


/» 

} else if (M is scalar) { 
generate(M); 


}; 

}; 


} else if (M is struct) { 
M.do generated; 

}; 

}; 

me .post generated; 

}; 


do_finalize() is { 

me. finalized; 

for each member M of me { 
if (M is a list of struct) { 
for i from 0 to M.sized { 
M(i).do finalized; 

}; 


Comments: 

-me refers to struct containing a method 
-only bold methods can be extended 


} else if (M Is composite) { 
M.do finalized; 

}; 

}: 

}; 



Figure 4.4 Pseudo Code for do_test(). do_generate(), do_ranQ, 
do_finalize(), and do_check() 



• Insert user’s program in the predefined execution flow by extending predefined meth- 
ods of sys and other user-defined structs 

For instance, the following e code fragment shows a simple e program that has one 
instance of data packet and sets the data payload content before the generation phase and sets 
the parity bit during run time phase: 




1 : extend sys { 

2 : my_data: data_packet; 

3 : 

4 : pre_generate() is also { 

5 : my_data.payload.data =8’b0; 

6 •• }; 

7 : 
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8 : run() is also { 

9 : my_data.payload.set_parity(1’bO); 



Observe that predefined methods of data packet could also be extended to accomplish the 
same behavior. 



4.4 Structure of an e Program 



4.4.1 Lexical Conventions 

User-defined names in e consists of any length combinations of alphabet characters, under- 
score, and digits (i.e. A-Z, a-z, 0-9). Valid names cannot start with a number. Though under- 
scores may appear at the beginning of a name, this is not recommended as these names have a 
unique meaning in the e language. Also, reserved keywords in the e language (see appendix B) 
cannot be used as user defined names. Figure 4.5 shows examples of valid and invalid names in 
the e language. 



Valid Names: 


Valid but Not Recommended 


Invalid Names 


• data 


• _datal 


• 1 packet 


• datal 


• __packet22 


• packet%l 


• datal_ 

• packet_13b 




• packet@port 


1 


Figure 4.5 Valid and Invalid e Names 


1 



e is a case sensitive language. A period is used to designate struct hierarchy traversal (i.e. 
packet.header). Also, in e, code blocks are enclosed with braces and end with a semicolon: 



4.4.2 Code Segments 

e programs are a collection of Code Segments. The beginning and end of a code segment are 
marked with beein-code <’ and end-code ‘> markers. The begin-code and end-code markers 
must be the only text on the line containing these markers (i.e. the line must start with the 
marker and end with the marker therefore containing only 2 characters). Each code segment is 
composed of multiple statements. 
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The most trivial e program (no program) is: 



2 : ‘> 



4.4.3 Comments 

All text outside code segments are considered to be comments. Additionally, comments within 
code segments can be marked with a double dash (--) or double slashes (//). Since multiple code 
segments can be included in the same file, it is possible to end a code segment, add comments, 
and then start a new code segment. 

The most trivial e program fully commented is: 



1 : this line is a comment since it is outside a code segment 

2 : this line is also a comment 

3 : 

4 : <’ 

5 : - this is a comment inside a code segment 

6 : // this is also a comment inside a code segment 

7 : ‘> 

8 : 

9 : this line is also a comment after the end of previous code segment 

10 : 

11 : 

12 : - more comments in a new code segment 

13 : // additional comments for the new code segment 

14 : ‘> 

15 : 

16 : end of file comments here 



4.5 Statements 



An e program is collection of code segments each consisting of a number of statements. The 
more commonly used statements are: 



• import statements 

• type declarations 

• struct/unit declarations 

• extensions 



These statements are described in the following sections. 
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4.5.1 Import statements 

Import statements are used to tell the compiler to load another e program file before compiling 
the current e program file. Import statements must appear before all other statements inside the 
first code segment in a file. A simple e program using the import statement is: 



1 : First code segment: 

2 : <’ 

3 : import header.e; 

4 : import packet.e; 

5 : — other user code after import statements in this code segment 

6 : > 

7 : 

8 : Second Code Segment: 

9 : <’ 

10: - import statements are NOT allowed in this code segment 

11 : - other user code in this code segment 

12 : ‘> 

I 



4.5.1.1 Import Order Dependency 

When importing files one at a time, care should be taken to import each file only after import- 
ing all files that contain declarations used in the file being imported. However this dependency 
may at times be difficult to track, and also circular dependencies may exist between declara- 
tions and instantiations in each imported file. Under such conditions, it is possible to import 
multiple files at the same time so that the e compiler can resolve the dependencies between 
code segments in these files. The files that are imported together are placed within parentheses 
as shown in this example: 



import (beader.e, packet.e); 

extend sys { 
p: packet; 

}; 



1 

2 

3 

4 

5 

6 
7 



4.5.2 struct Declaration Statement 

The struct statement is used to define new composite data types. Structs contain data members 
to store data and methods to perform operations on its data members. Structs may also contain 
other verification related constructs (i.e. keep statements, events, coverage definitions, etc.). 
These fields are discussed in detail in their corresponding sections. 
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4.5.2. 1 Struct Data Members 



Struct data members may be scalar members, list members, or composite data types (i.e. previ- 
ously defined structs). 



Examples of scalar data members include: 



struct data_holder { 


datal : 


uint[0.. 100] (bits:7); 


flag: 


bool 


timel: 


time; 


data2: 


uint(bits:16); 


packetl : 


packet; 



As shown in this example, other user-defined structs (i.e. packet) can be used as a type for 
a struct member. Examples of list data members include: 

1 : struct data_holder { 

2 : datajist: list of uint; 

3 : booljist: list of bool; 

4 : data_list[1 6]: list of uint; 

5 : packet_list[2]: list of packet; 

6 i * 

In this example, the size of the list is explicitly set to 16. Keyed lists can also be defined to 
allow for searching lists using values of list members. 



4.5.2.2 Methods 



Methods are struct members that are used to perform operations on struct data members, or any 
other value that the method can access. Methods are either procedures or functions and may or 
may not consume time. Examples of methods are: 



1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 



struct data_holder { 

data: uint (bits: 16); 

set_data(val: uint (bits:16)) is { 
data = val; 

1 ; 

get_data_version 10: uint (bits: 16) is { 
return data; 

1 ; 

get_data_version2(): uint(bits:16) is { 
result = data; 

1 ; 
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Methods are defined by specifying the name, the parameter list, the return type (if any) 
and the actions in the method. The above example shows two variations of returning a value in 
a method. In the first version (get_data_version1()), the value for data is explicitly returned by 
issuing a return statement. In the second version (get data version2()), the return value for the 
method is returned by assigning it to the reserved keyword result. When the method returns 
after completion, the value of result is returned. 



4.5.3 Type and Subtype Declaration Statements 

The following Boolean and numeric types are predefined ine: 

• int, 

• uint, 

• bit, 

• nibble, 

• byte, 

• time, 

• bool 

New scalar subtypes, enumerated types, and struct subtypes can be defined in an e pro- 
gram. The following sections provide an overview of these constructs. 

4.5.3.1 Enumerated Type Declarations 

Enumerated types are defied by specifying the possible values for the new type as shown in this 
code fragment. The new type can then be used to define the type for new data objects. 



1 : type color_t: [RED, BLUE, GREEN]; 

2 : 

3 ; extend sys { 

4 color; color_t; 

5 : run() is also { 

6 ; color = RED; 

7 : }; 

8 : }; 



The enumerated values of the new type can be used in all expressions including the assign- 
ment shown in this example. 
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4.5.3.2 Scalar Subtype Declarations 

Scalar subtypes are defined by modifying the bit size and/or the range for a predefined type. If 
both bit size and the range are specified for a subtype, then the smaller range will be the effec- 
tive range of a scalar subtype. 



1 : type int_subrange: int [0.. 100] (bits:12); 

2 : type int_subrange1 : int[0.. 100] (bits:3); 

3 : type inti 6: int (bytes:2); 

4 : type inti 00: int [0..100]; 



The subtype declaration shown in this example limits the range for int_subrange to 
between 0 and 100, and sets the size of the field to 12 bits. This example limits the range for 
int_subrange1 to 0 to 7 since the bit size of 3 only allows for values up to 7 to be represented., 
Either the bit size or the range can be omitted in this construct as shown in this example. 

4.5.3.3 Struct Subtype Declarations 

When declaring a struct, it is possible to use one of its members as a subtype determinant. The 
struct definition can then be customized for its different subtypes indicated by different values 
of this subtype determinant field. 

In this example, a pixel is defined to have either a RED or a BLUE color. Depending on its 
color, the tone is defined to have different types representing different variations of BLUE or 
RED. The when constmct is used to define subtypes of pixel so that the struct members are dif- 
ferent depending on the value of color field. This example also shows the syntax for instantiat- 
ing these subtypes where they are instantiated under sys. Figure 4.6 shows the instance 
hierarchy starting at sys for this example. 




Figure 4.6 Struct instance hierarchy for struct subtypes 
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type color: [RED, BLUE]; 
type red_tone: [RED1, RED2, RED3]; 
type blue_tone: [BLUE1, BLUE2, BLUE3]; 
struct pixel { 

colorl : color; 
when RED pixel { 
rtone: red_tone; 
id: uint; 

}; 

when BLUE pixel { 

btone: blue_tone; 
is_real: bool; 

}; 

}; 

extend sys { 

r: RED pixel; 
b: BLUE pixel; 

}; 



4.5.4 Extension Statements 

The aspect oriented features of e allows different language constructs to be extended after their 
initial definition. The constructs that can be extended are structs/units, methods/TCMs, enu- 
merated types, coverage groups and items, and events. Extension of structs, methods in structs, 
and enumerated types are described in this section. Extension of remaining constructs are 
described in their corresponding chapters. 

Enumerated types are extended as shown in this example: 



1 : type color: [RED, BLUE, GREEN]; 

2 : extend color: [YELLOW]; 



I 

After processing the two lines, the definition for color will include four colors of RED, 
BLUE, GREEN, and YELLOW. Note that the original declaration of a type and its extensions 
may be located in different files. An enumerated type can also be extended multiple times. 

Structs can also be extended using the extend mechanism. For example: 



1 : struct packet { 

2 : header: packet_header; 

3 : }; 
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4 : 

5 : extend packet { 

6 : data[16]: list of uint(bits:16); 

7 : }; 



i : 

In addition, method definitions in a struct may also be extended. Methods are extended 
using keywords of is empty, is undefined, is first, is only, and is also. 

For example, the following code adds outf actions to the set_data() method so that a text is 
printed before and after the assignment operation in this method: 
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struct data_holder { 

data: uint (bits: 1 6); 

set_data(val: uint (bits: 16)) is { 
data = val; 

}; 

set_data(val: uint (bits: 16)) is first { 

outffthis text is printed before val is assigned to data"); 

}: 

set_data(val: uint (bits: 16)) is also { 

outf(“this text is printed after val is assigned to data”); 

}; 



To override the definition for a method, the is only keyword is used. The definition for the 
set_data() method is changed in the following example to assign the value (val+1) to the data 
field. 
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struct data_holder { 

data: uint (bits: 16); 

set_data(val: uint (bits:16)) is { 
data = val; 

}: 

set_data(val: uint (bits: 1 6)) is only { 
data = val +1 ; 

1 ; 
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When using is empty, an empty action block is defined for a method. This means that no 
error will be reported when using this extension mechanism. Using is undefined removes any 
previous block defined for a method. The is undefined extension for a method can only be used 
after defining an action block for that method. 

Extensions to a method are applied in the same order that the compiler processes the 
extension definitions. For example, if the first extension that is processed is an is only type, 
then the original definition of the method is completely replaced and all following extensions 
are applied to the new method definition. The method signature (name, parameter list, return 
type) should be exactly the same in the original definition as all extensions of that method. 



4.6 Concurrency and Threads 



Concurrency is a powerful programming concept that allows for intuitive and effective model- 
ing of systems that are composed of concurrently operating objects. Due to inherent concur- 
rency of hardware models, and the requirements for interacting with such models, supporting 
concurrency is in fact considered a requirement for languages that are used for design and veri- 
fication ofhardware systems. 

The two fundamental concepts in concurrent programming are processes and resources. A 
process refers to sequential execution of a task and has its own thread of execution. Resources 
refer to the necessary elements required for executing a process (i.e. memory space, I/O 
devices, etc. ). A concurrent program consists of two or more processes. Processes that share the 
same address space are called light-weight-processes or threads. Concurrency support in most 
programming languages is targeted for the same address space as the program itself. Sharing 
the address space allows multiple threads to access the same variables in the program runtime 
environment and therefore allows threads to communicate through these shared variables. The 
processes inane program share the same address space and are therefore considered threads. 
Therefore this discussion is focused on threads. 

In a multi-threaded language such as e , mechanisms should be provided for suspending a 
running thread and to restart a suspended thread in order to give all threads an opportunity to 
execute. Similarly, the language should provide support for communication between multiple 
threads. To support concurrent programming, a language should provide utilities for support- 
ing: 

• Concurrently running threads 

• Thread synchronization 

• Starting new threads 

• Suspending a running thread 

• Ending (removing) a running thread 

• Restarting a suspended thread 
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The e programming language has full support for concurrent programming. Events and 
Temporal Expressions are used for thread synchronization (i.e. deciding on when to start a new 
thread or restart a suspended thread). Additional constructs are provided for thread control, 
including creating new threads and suspending threads. Time Consuming Methods (TCMs) are 
used to further facilitate start of new threads and for enabling more detailed thread synchroniza- 
tion. These language features are discussed in the subsequent sections. 

The runtime environment for an e program consists of a thread scheduler that has knowl- 
edge of all software threads at any given time during the program runtime. At each iteration of 
its main loop, this scheduler identifies all qualified threads (i.e. threads that are ready to be 
resumed based on their restart conditions). It then restarts each qualified thread from the point 
where it was suspended until that thread suspends under its own control (i.e. by calling the wait 
or sync action, calling a TCM which includes an implicit sync at its sampling event, or termi- 
nating). A new iteration starts when all qualified threads at the previous iteration have been 
restarted. Each iteration of this scheduler corresponds to one rick of the runtime environment. 



4.6.1 Events and Temporal Expressions 

In the e language, events are used to synchronize execution between threads 6 . Events can be 
emitted explicitly or implicitly. The event keyword is used to define an event. The emit action 
is used to explicitly emit an event. Events are emitted automatically by describing an event as a 
function of other events and Boolean conditions. Temporal expressions are used to describe 
such functions. 

The following e program shows an example of defining and emitting named events. It also 
shows how events are used with the on construct. 
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struct transmitter { 

event transmit_completed; 
transmit_count: uint; 
keep transmit_count == 0; 

on transmit_completed { 
transmit_count += 1; 

1 ; 



post_transmit_operations() is { 
emit transmit_completed; 

1 ; 



L 



6 ' Events are also used to synchronize to external simulators. This topic is discussed as part of verification 
support in the e language. 
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The e language defines a number of predefined events that are emitted by the e program 
execution environment. The most fundamental predefined event is sys.any. This event is emit- 
ted for every iteration of the thread scheduler. 

4.6.1. 1 Temporal Expressions 

Temporal Expressions are used to describe temporal behavior using events and temporal opera- 
tors. Temporal expressions produce events that are triggered when the temporal expression 
evaluation succeeds. Temporal expressions can be used in the following constructs: 

• wait and sync actions in time consuming methods 

• to define named events, and in expect or assume struct members 

A temporal expression is evaluated at eveiy occurrence of its sampling event. A sampling 
event is defined by attaching it to a temporal expression as follows: 

TE @ sampling-event 

The sys.any predefined event is the default sampling event for all temporal expressions. A 
sampling period is the time between current occurrence of a sampling event and the previous 
occurrence of a sampling event. Sampling period is an important concept in evaluating tempo- 
ral expressions since the temporal operators are based on how temporal expressions evaluate 
during the sampling period. 

All temporal expressions are constructed by combining Base Temporal Expressions using 
temporal operators. The base temporal expressions are: 

Event Base TE: @named-event @sampling-event 

Change Base TE: rise(scalar exp) @sampling-event 

fall(scalar exp) @sampling-event 
change(scalar exp) @sampling-event 

Boolean Base TE: true(boolean-expression) (©sampling-event 

For event base temporal expressions, the temporal expression succeeds if named-event is 
emitted at any time during the sampling period specified by the sampling event of the temporal 
expression. In contrast, a Boolean base temporal expression succeeds only if the Bool- 
ean-expression evaluates to true when the sampling event is emitted. In other words, a Boolean 
base temporal expression is evaluated only when the sampling event is activated. Similarly, 
scalar expressions for a change base temporal expression are evaluated only at occurrence of 
the sampling event. Figure 4.7 shows examples of how these base temporal expressions are 
evaluated. 

Some commonly used temporal operators are: 

Logical Operators: (not TE), (TE and TE), (TE or TE) 

T ransition Operators: rise(scalar exp), fall(scalar exp), change(scalarexp) 

Fixed Repetition Operator: [expfTE 
Sequence Operator: {TE; TE} 

Examples that use these temporal operators include : 

TE1: ((not @A) or @B) @clk 

TE2: ([12]*@A)@clk 
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Figure 4.7 Evaluating Base Temporal Expressions 



TE3: {not @A; [3]*@B} @clk 

TE4: cycle @dk 

TE1 succeeds when event A is not detected or event B is detected during a sampling period 
of event elk. TE2 succeeds when event A occurs 12 times in the previous 12 sampling periods 
defined by event elk. TE3 succeeds when event A in not detected during one sampling period 
and event B is detected in the following 3 sampling periods of event elk. In TE4, cycle is an 
alias for the sampling event (i.e. @clk ). In essence, TE4 succeeds when event @clk occurs. Tem- 
poral operators are discussed in detail in chapter 9. 



4.6.2 Time Consuming Methods (TCMs) 

Time consuming methods (TCMs) are methods that consume simulation time. TCMs are cre- 
ated by tagging a method with a sampling event. TCMs may contain synchronization actions 
(which use temporal expressions). The default sampling event of a TCM is used as the default 
sampling event for any temporal expression that is evaluated as part of executing that TCM. 

In this example, method inject_packet() is a time consuming methods since it is tagged with 
the default sampling event @clk. 



1 : struct packet { 

2 : inject_packet() @clk is { 

3 : }; 

4 : I; 



L 
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TCMs may be called only from other TCMs while regular methods may be called from 
both TCMs and regular methods. 

4.6.3 Thread Control 

In multi-threaded languages, the program runtime for a program execution consists of many 
Runtime Cycles . A runtime cycle refers to a slice of time where all Qualified Threads are given 
a chance to execute. A qualified thread during a runtime cycle is a thread whose requirements 
for reactivation are satisfied. During each such cycle, all qualified threads are executed until 
each thread either exits or is suspended. At this time, the current runtime cycle is completed and 
a new runtime cycle is started. Within the context of hardware simulation, advancement from 
one runtime cycle to the next is used to model progression of simulation time 7 , while the execu- 
tion within a runtime cycle is assumed to take place in zero simulation time. 

To support concurrent programming, the e language provides: 

• Concurrency Actions: start, first of, all of 

• Synchronization Actions: wait, sync 

The start action is used to explicitly start a new thread. The thread that issued the start 
action, and the new thread become independent threads that are suspended and restarted inde- 
pendently of each other and based on their suspend and resume conditions. The first of and all 
of actions are used to start new threads while suspending the thread that issued these actions. 
For the all of action, the original thread is resumed after all started threads are completed. For 
first of action, upon completion of any of the threads that were started, all started threads are 
ended and the original thread continues its execution. A visual representation of this behavior is 
shown in figure 4.8. 

wait and sync actions both cause the executing thread to suspend until the temporal 
expression attached to these actions succeeds. For sync action, the thread continues to execute 
if the temporal expression attached to the sync action succeeds in the same tick. The thread sus- 
pended by a wait action requires the sampling event of the TCM to emitted once before it 
resumes. A visual representation of this behavior is shown in figure 4.9. 

The following example demonstrates how new threads are suspended and resumed using 
the wait and sync actions: 



1 : struct packetjnjector { 

2 : event dk; 

3 : injector() @clk is { 

4 : wait cycle; 

5 : inject_next_packet(); 



7 It is in general possible to have multiple runtime cycles without advancing the simulation time, as is the 
case with HDL simulator delta cycles. 



75 





6 

7 

8 

9 

10 
11 
12 

13 

14 

15 



wait cycle; 
inject_next_packet() ; 

}; 

runO is also { 

start injector(); 

}: 

}; 

extend sys { 

packetjnjector; 

}; 



| 

In this example, named event elk in packet jnjector is emitted from other parts of the pro- 
gram not shown in this example. The elk event is used as the default sampling event for the 
injectorl) TCM. The run() method of packetjnjector is extended to start the injector() TCM. 
injectorj) waits for the first occurrence of the default sampling event (i.e. elk). It then injects the 
next packet. It then suspends waiting for the next default sampling event (waiting for a cycle). 
After getting restarted, it injects the next packet. It then returns (i.e. method completes) which 
terminates the thread started in the run() method. At that time, since there are no more sleeping 
threads, the run phase of program execution completes and the next phase is started. 

The use of first of and all of actions are shown in this example: 
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In this example, the first of statement completes after one occurrence of event elk since 
among the three threads that are started in this action, the first thread completes first and within 
one cycle. In this example, if the first of action is changed to an all of action, then this action 
will complete after 3 occurrences of the elk event since the longest running thread takes 3 clock 
cycles. 



Rules to keep in mind when working with threads: 

• Only TCMs can be started using the start action. 

• The start action can be called in either methods or TCMs. 

• first of and all of actions can only be used in TCMs. 

• The sampling event of aTCM containing a synchronization action (i.e wait, sync) is the 
default sampling event for evaluating the temporal expression attached to these syn- 
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chronization actions. 

• Execution flow moves to the next thread only when a running thread completes or is 
suspended using a synchronization action. 

• stop_run() method can be used to explicitly end all running threads. 

• Calling a TCM from another TCM results in an implicit sync action using the sampling 
event of the called TCM. Therefore calling TCMs may potentially suspend the current 
thread. 

4.6.4 Semaphores 

Semaphores are used to provide mutual exclusion and synchronization across multiple threads. 

These constructs are described in the following subsections. 



4.6.4. 1 Mutual Exclusion 

It is sometimes required to give a thread exclusive access to a shared resource. The thread that 
is granted exclusive access is called the locking thread. This exclusive access is necessary in 
order to prevent other threads from accessing or modifying a resource while the locking thread 
is temporarily suspended. Consider a TCM that interacts with a DUV port through a 
multi-cycle handshaking protocol. Clearly, no other thread should be accessing the same DUV 
port signals while this TCM is suspended because of the protocol requirements. 

e provides the locker construct when a resource can be used by only one user (i.e. thread) 
at a time. The following example shows the use of this construct where the resource in consid- 
eration is a bus interface TCM: 



1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 
13 



struct bus_master { 

Ikr: locker; 
event elk; 

write(addr: uint(bits:24), data: uint(bits:32)) @clk is { 
lkr.lock(); — start mutual exclusion 
— start multi-cycle bus write operation 



- end multi-cycle bus write operation 
Ikr.releaseO; - end of multi-cycle bus write operation 

}; 

}; 



In the above, predefined lock() and releasel) methods of locker are used to mark the 
beginning and end of code region that should only be used by one thread at a time. 

e also provides the semaphore construct to provide a general solution to the mutual exclu- 
sion (mutex) problem where a resource can be used by N number of users at the same time, 
where N can be configured in the semaphore. Semaphores in e use a fair FIFO type implemen- 
tation that assures all waiting threads get a fair chance to use that resource. 
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The above discussion applies only to cases where one resource is being shared across mul- 
tiple threads. In cases where multiple resources are required for a code segment (i.e. a write 
operation that requires exclusive access to two or more DUV ports), then use of semaphores as 
outlined above may lead to a deadlock. For a discussion of mutex algorithms that avoid such 
deadlocks, the user is referred to any text covering concurrent programming. 



4.6.4.2 Thread Synchronization 

Thread synchronization is modeled as a producer-consumer type interaction. In this type of 
synchronization, threads marked as producers can only resume when the resource they have 
produced has been consumed. Threads marked as consumers can only resume when they con- 
sume a product that is made available by a producer. This concept is shown in figure 4. 10. Note 
that multiple producers and multiple consumers can synchronize through the same resource. In 
this case, a producer will resume when its product is consumed by any of the consumers, and a 
consumer resumes when a product is made available to it by any of the producers. 




Consumer 1 
Consumed 
Consumed 



Figure 4.10 Producer-Consumer Model of Thread Synchronization 



Rendezvous semaphores are provided in e using the rdv_semaphore and are used to 
implement this type of synchronization. The use of these semaphores is shown in the following 
example: 
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extend sys { 

rsem: rdv_semaphore; 



produce_and_place_in_fifo(id: uint) is empty; 
take_from_fifo_and_consume(id: uint) is empty; 

producer(id: int) @any is { 
while TRUE { 

produce_and_place_in_fifo(id); 

rsem.upO; -- wait for a consumer to use the resource that was just produced. 

}; 

}; 

consumer(id: int) @any is { 
while TRUE { 

rsem.down(); - wait for a producer to make a resource available 
take_from_fifo_and_consume(id); 

}: 

}; 

run() is also { 

start producer(1 ); 
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24 : 


start producer(2); 


25 : 


start consumer(3); 


26 : 


start consumer(4); 


27 : } 




28 : }; 




29 : ‘> 





In the above, each consumer calls the up() predefined method of the semaphore to wait for 
a consumer to call the down() predefined method. Every time a product is consumed by a con- 
sumer, both threads for producer and consumer resume. In this case, the thread for producer 
resumes first, followed immediately by the thread for the consumer. 



4 . 7 Summary 



This chapter introduced the concepts and structures in e that describe the organization of e as a 
programming language. The discussion presented e as a powerful programming language that 
can be used for effective implementation of general purpose programs. The concepts of aspect 
oriented programming, declarative programming, and concurrent programming constructs in e 
make e a good candidate for a slew of programming environments. The e programming lan- 
guage provides an extensive set of abstractions and constructs for verification projects. The 
verification aspects of the e language are discussed in chapter 5. 
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e as a Verification 
Language 



The e language is a powerful hardware verification language architected on the requirements of 
verification methodologies essential to successful completion of complex verification projects. 
e not only provides the necessary constructs to facilitate the successful and efficient develop- 
ment of verification programs, it also guides the programmer towards a programming style that 
is better suited to recommended verification methodologies. The execution order of an e pro- 
gram, as described in the previous chapter, is one example of the close relationship between e 
and verification projects. This chapter describes the e constructs that facilitate the implementa- 
tion ofe verification programs. 

The abstractions required for implementing a verification program are directly tied into 
the activities that are performed during a verification project. Verification related constructs and 
abstractions in the e language are in direct correlation with the verification facilities required 
for implementing these verification activities. Verification activities include: 

• Simulation Abstraction 

• Generating Stimulus 

• Driving Stimulus 

• Collecting Device Response and Result Checking 

• Measuring Verification Progress and Coverage Collection 

Table 5.1 lists these verification activities and the verification facilities and e language fea- 
tures that are required for performing these activities. This chapter introduces the e language 
features listed in this table. 
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Table 5.1: Verification Activities ande Language Features 



Verification Activity 


Verification Facility 


e Language Feature 


Simulation Abstraction 


Notion of Concurrency 


Concurrency and Thread Control 


Stimulus generation 


Constrained Random Generation 


Constrained Random Generation 


Stimulus Variation for Specific Verifi- 
cation Requirements 


Extension Mechanisms 


Driving Stimulus 


Interfacing with HDL Simulator 


HDL Interface, e-ports 


Associating Verification Objects with 
Simulation Module Instances 


Units 


Synchronizing with HDL Simulator 


Events, Temporal Expressions 


Moving from Data Abstraction to 
Physical Abstraction 


Packing 


Applying Stimulus 


Methods, TCMs 


Result Checking 


Collecting data from HDL Simulator 


HDL Interface, e-Ports 


Moving from Physical Abstraction to 
Data Abstraction 


Unpacking 


Data Checking 


Scoreboarding 


Timing Protocol Checking 


Temporal Expression 


Coverage 


Coverage 


Coverage 



5.1 Constrained Random Generation 



The constrained random generation feature in e randomly creates a struct hierarchy for data 
objects and assigns random values to its scalar fields (leaf nodes) 1 . This generation capability is 
an implicit phase of the execution order in ane program when the struct hierarchy rooted atsys 
is randomly generated and populated. Generation can also be used explicitly during the simula- 
tion runtime. The pseudo code given in figure 4.4 shows the order of generation for a struct 
hierarchy. 



1 A struct hierarchy may in fact have different valid structures. Different valid struct hierarchies for the same 
object type are possible due to: 1 ) struct members that are lists of structs with potential different size lists, and 
2) struct subtypes which may have different members all together depending on the struct type. 
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In the absence of any generation constraints, generation routines populate scalar fields of a 
struct hierarchy with fully random values in the range of each scalar type (i.e. an enumerated 
scalar type is assigned a value from its possible enumerated values). 

Fully randomized value assignment is not particularly useful since any realistic scenario 
for generating values requires valid or interesting ranges to be defined for data objects and that 
relationships between separate fields are defined during generation. The generation facility ine 
provides a powerful constraint solver engine that allows concise and easy constraint specifica- 
tion for the randomly generated values. In section 5.1.1, the e generation mechanism without 
constraints is described. Constraint specification and usage is introduced in section 5.1.2. 



5.1.1 Random Generation 

In e, the fundamental generation activity is the assignment of random values to members of a 
struct. For a struct without any subtype definitions, a random value is generated for struct mem- 
bers in their order of appearance in the struct declaration so that for each member: 

• if a scalar type: assign random value in its full range 

• if a scalar subtype: assign random value in its valid range 

• if an enumerated type: assign random value from enumerated literals 

• if a list: generate list size, and then generate list items one at a time starting from the 
first list element 

• if a struct: generate this member struct using this same procedure before moving on to 
next struct member 



The steps described above lead to a depth first order of generation for struct members 
where the struct hierarchy rooted at a struct member, which itself is a struct, is fully generated 
before moving to the next struct member. 



It is possible to prevent generation for a struct member by prefixing that struct member 
with the “!” character. Such fields will not be assigned during random generation process. The 
generation order for such an e code segment is shown in figure 5.1. 
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type address_type: [LAN, NET]; 
struct address { 

Ian: uint(bits:48); 
type: address_type; 

}; 

struct packet { 

Isize: uint; - will not be generated, 
src: address; 
dest: adress; 



extend sys { 
packet; 

1 ; 
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Figure 5. 1 Struct Hierarchy Generation Order 



Even in the absence of generation constraints, the generation order may change from the 
default order for a struct that has subtypes. For struct subtypes, one or more members of that 
struct are used as subtype determinant struct members . Subtype determinant members are often 
used to create struct subtypes that could potentially have different members. Therefore in order 
to generate a struct subtype, it is necessary to first assign a value to the subtype determinant 
members of that struct. The generation order is therefore modified to assign a value to subtype 
determinant members before any of the members specific to that subtype are assigned a value. 
The affect of subtype definition for the following e program is shown in figure 5.2. 




Figure 5.2 Struct Hierarchy Generation Order for Struct Subtypes 



1 : <’ 

2 : type address_type: [LAN, WAN]; 

3 ; struct address_1 6 { 
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4 : Ian: uint(bits:1 6); 

5 : netl 6: uint(bits:16); 

6 : }; 

7 : struct address_32 { 

8 : Ian: uint(bits:16): 

9 : net32: uint(bits:32); 

10 : }; 

1 1 : struct packet { 

1 2 : data[1 6]: list of uint; 

1 3 : when LAN packet { 

14 : addr16: address_16; 

15 : }; 

1 6 : when WAN packet { 

17 : addr32: address_32; 

18 : }; 

19 : atype: address_type; 

20 : }; 

21 : extend sys { 

22 : packet; 

23 : }; 

24 : ■> 



5.1.2 Generation Constraints 

It is often necessary to constrain the generation process so that a specific verification scenario 
or a group of verification scenarios can be targeted, e provides a powerful constraint solver 
engine that allows constraints to specify: 

• A range of valid values for generated fields 

• Relationships that should be maintained between generated fields 

The keep keyword is used to specify constraints for generated fields. In this example, con- 
straints are specified to limit the valid range for length and height and to define a relationship 
between these members: 




1 : struct rectangle { 

2 : length: uint; 

3 : keep length in [1.. 20]; 

4 : 

5 : height: uint; 

6 : keep height in [1 ..20]; 

7 : 

8 : keep height < length; 

9 : }; 




During the generation process, the constraint solver generates values for length and width 
so that the specified constraints are met. 
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Constraint definitions in e are declarative statements, meaning these constraints are 
declared as struct members and are considered anytime their affected fields are generated any- 
where in the e program, or anytime during the simulation runtime. 

It is often desirable to have a default constraint for a field, which can later be changed 
depending on stimulus generation requirements. The keep soft keyword is used to define a 
default constraint that can be overridden in later extensions or in subtypes of a struct using a 
keep statement. For example: 
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type box_type: [SQUARE, RECTANGLE]; 
struct box { 

type: box_type; 

length: uint; 
height: uint; 

keep soft height == length; 

when RECTANGLE box { 
keep height < length; 

1 ; 

}; 



In this example, if the box type is generated to SQUARE, then the default soft constraint 
will guarantee that the generated values for length and height are equal when randomly gener- 
ated. However if the type is generated to be RECTANGLE, then the constraint defined in the 
RECTANGLE subtype will override the default constraint. During the generation phase, soft con- 
straints are applied only if they do not contradict the combination of all the hard constraints for 
that field. This means that a soft constraint is applied if it reduces the valid range for a field. 
Also, soft constraints are applied in the reverse order that they are processed by the e compiler. 
For example: 
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struct box { 

length: uint; 
height: uint; 

keep soft length == height; 
keep soft length < height-1 ; 
keep length in [10..20]; 
keep height in [1..11]; 



In the above example, first the hard constraints on lines 6 and 7 are considered. Then the 
second soft constraint on line 5 is considered and rejected as it contradicts with the collective 



86 



The e Hardware Verification Language 




e as a Verification Language 



result of all hard constraints. The soft constraint on line 4 is considered next, and is accepted 
because it can be satisfied while considering the collective effect all previous constraints. 

Constraints can affect the generation order that was described in the previous section. 
Constraints fall into two categories: 

• Unidirectional Constraints 

• Bidirectional constraints 

Bidirectional constraints do not affect the order of generation. I Jnidirectional constraints 
however require a special ordering of the generated fields and therefore affect the order of gen- 
eration. Table 5.2 shows examples of unidirectional constraints and the resulting order imposed 
on fields used in these constraints. 



Table 5.2: Unidirectional Constraints 



Operation Type 


Example 


Generation Order 


Multiply/Divide 


keep area = height * length 


height, length, and then area 


Method Call 


keep area = compute_area(length, height) 


length, height, and then area 


Bit Extraction 


keep length == height[a:b] 


a and b, followed by length, 
followed by height 


When Subtype 


when SMALL’ size box {keep length== 1; } ; 


first size, then length 


Explicit Order 


keep gen (length) before (height) 


length and then height 



5.1.3 Pre-Run vs. On-the-Fly Generation 

As discussed earlier, a generation phase is performed as part of the execution flow of an e pro- 
gram. This implicit generation phase is performed before the simulation run is started and is 
called the pre-run generation phase. As part of this step, the struct hierarchy rooted at sys is 
generated and populated with random values meeting the declared constraints. Any data object 
instantiated under sys will be generated as part of this pre-run generation phase. 

It is possible to generate values during simulation runtime and specify additional con- 
straints during run time generation. In the following example, calling the user-defined method 
gen_at_runtime() during simulation runtime assigns constrained random values to the fields of 
packet_injector struct. Note that constraints are declared for packet struct members in the defini- 
tion of packet struct on lines 3 and 5. Additional constraints are also declared for packet struct 
members for the specific instance of this struct in packet_injector struct on lines 1 1 and 12. 
Additional constraints are also specified during the on-the-fly generation steps for packet mem- 
bers, and also for the number of packets to be generated. Due to combination of all specified 
constraints, during the runtime generation, the generated value for packet.header is in the range 
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5.2 HDL Simulator Interface 

Seamless interface with the hardware simulation environment is considered another important 
requirement of a verification language, e provides extensive support for HDL simulator access. 

Signals in the hardware simulator can be accessed and modified directly from an e pro- 
gram. To access an HDL signal, its name is placed in single quotes (‘). The following example 
shows the assignment of value l’bl to signal HDL_signal_name in the HDL simulator. 

‘HDL_signal_name’ = 1’bl; 

If the name of the signal is provided by a variable, then that variable is further placed in 
parenthesis before being placed in single quotes. For example, given e string variables 
signal_name (a string) and signaLid (a uint), the following notation can be used to assign a value 
to that signal: 

‘HDL_signal_path/(signal_name)_(signal_id)’ = 1’bl; 

The following program shows the interface mechanism for simulator signals: 
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struct hdljnterface { 

signaLname: string; 

keep signaLname == “~/top/data[8:0]”; 
signal_value: uint(bits:9); 



write_and_read() is { 

signal_value = ‘(signaLname)’; 
‘(signal name)’ = signal value; 




signal_value = '~/top/data[8:0]’; 
'~/top/data[8:0]’ = signal_value; 

}; 



L 



In this example, method write_and_read() uses a string variable as the HDL simulator signal 
name. In method write„and_read_direct(), signal names are specified directly. 

When driving HDL signals from an e program, it is possible to use force and release state- 
ments to assign and remove the assignment of a hard value to an HDL signal. In e, the verilog 
variable and vhdl driver statements are used to describe specifically how an HDL signal is 
driven from the e program (when to drive, how long to drive, when to stop driving). 



5.2.1 Multi-Valued Logic 

e predefined scalar types support only two-valued logic. As a result, x and z values are trans- 
lated into binary values when read from the HDL simulator. When reading HDL signals: 

• all x values are translated into a binary zero 

• all z values are translated into a binary one 

HDL signals can be driven with x or z from an e program: 



1 : struct hdljnterface { 

2 : drive_x_and_z() is { 

3 : '~/top/data[3:0]’ = 4’b01 xz; 



It is also possible to detect if an HDL signal has an x or z value. The @z operator returns a 
1 if an HDL signal has a z value. @x operator returns a 1 if an HDL signal has an x value. 
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struct hdljnterface { 
data: uint(bits:4); 
xdata: uint(bits:4); 
zdata: uint(bits:4); 
drive_and_read_x_and_z() is { 
‘~/top/data[3:0]’ = 4'b01 xz; 
data = ‘~/top/data[3:0]’; 
xdata = ‘~/top/data[3:0]@x’; 
zdata = ‘~/top/data[3:0]@z’; 

}; 



- assigning 4 valued logic to HDL signal 
-- data is set to 4’b0101 
-- xdata is set to 4’b0010 
-- zdata is set to 4’b0001 



I 

Comments on lines 7,8, and 9 show the values of data, xdata, and zdata t that will be 
printed after reading signal values from the HDL simulator. 



5.3 HDL Simulator Synchronization 



The e language provides the predefined event sim to synchronize operation with the HDL sim- 
ulator. This predefined event is used as the sampling event for temporal expressions that moni- 
tor signal changes in the HDL simulator. The following usage ofsim event is allowed: 



event rise_event 
event fall_event 
event change_event 
event event_detect 



is rise('hdl_signal_name’) @sim 
is fall('hdl_signal_name’) @sim 
is change(‘hdl_signal_name’) @sim 
is change( ‘verilog_event_name’) @sim 



After analyzing all such expressions in thee program, the e compiler automatically creates 
the necessary interface to the HDL simulator so that a every time a monitored HDL signal is 
changed, a call back will be made from the simulator to the e program runtime environment. 



An event that is defined using the @sim predefined event can be used as sampling events 
for TCMs and as part of temporal expressions. In doing so, it is possible to synchronize thread 
execution in an e program to signal transitions in the HDL simulator. 



5.3.1 Notion of Time 

All thread executions that take place in the same runtime cycle (i.e. tick) are assumed to take 
place in zero simulation time. When a simulator is attached to the e runtime environment, the 
predefined variable sys.time is updated with the HDL simulator time value every time a call- 
back is made to the e runtime environment. In an HDL simulator, it is generally possible for 
multiple delta cycles to take place at the same simulation time. Under such conditions, multiple 
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callbacks to the e runtime environment may also take place at the same simulation time. The 
predefined event sys.new_time is emitted when simulation time is advanced. 

When no simulator is attached to the e runtime environment, the sys.time variable counts 
the number of sys.any events that have occurred since the beginning of program execution. 



5.4 Units 



Verification modules that interact with an HDL simulator must be relocatable. If a verification 
module interacts with a number of signals in an HDL module, then the implementation of the 
verification module should only depend on the HDL module with which it interacts, and should 
not depend on where in the HDL design hierarchy this HDL module is located. This require- 
ment serves two purposes: 

• Simplifies migration from module level to system level simulation 

• Improves verification module reusability 

During module level verification, an HDL module resides at the top level HDL design 
hierarchy. During system level verification, however that same HDL module will be placed in 
its final position in the system level design hierarchy. The same verification module should be 
usable without any modifications as the project moves from module level to system level veri- 
fication. 

Additionally, an HDL module can be instantiated multiple times in the system level envi- 
ronment. For example, the same ethemet port implementation is instantiated multiple times in 
an ethemet switch. The verification module for the ethemet port should therefore be usable for 
all instances of this port without requiring any modifications. 

The unit constmct is used for building relocatable e verification modules. Units are the 
same as structs in all aspects, except the following: 

• Units are generated only during the pre-run phase and cannot be generated during runt- 
ime. 

• Units are instantiated with an additional is instance keyword. If the is instance key- 
word is missing for a field, then that field is assumed to be a reference to a unit instance. 

• Units are associated with a specific HDL hierarchy path. All HDL signal references 
inside a unit (unless using an absolute path stalling with are assumed to be relative 
to the unit HDL path. This path is specified using the predefined unit method 
hdl_path(). 

• The predefined get_enclosing_unit() method of a struct or unit instance can be used to 
find the closest ancestor unit of a given type in its instance hierarchy. 

• Units can only be instantiated in units. 

These unit features are demonstrated in the following example. In this example, an 
hdljnterface unit is first instantiated under sys. The HDL path for this instance is set to the 
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absolute path of “-/hdljop”. Unit hdljnterface is declared next. Data member value to write of 
this unit is a value that will be written to HDL signals. This unit also instantiates an hdLwriter 
unit and sets its HDL path to “channel”. Note that this HDL path is relative to the HDL path of 
the unit where hdljnterface will be instantiated. Next, unit hdLwriter is declared. This unit has a 
string member signal_name, which is the target HDL signal for the write operation. This name is 
constrained to “data,” which again, is relative to the HDL path of the hdLwriter unit. hdLwriter 
unit also contains a pointer to the hdljnterface unit that contains it. The get_enclosing_unit() 
method is used to constrain the value of this reference to the closest parent of hdLwriter which is 
of type hdljnterface. Finally, the write() method of hdLwriter writes the value of valueJo_write to 
the HDL simulator. 



1 : unit hdljnterface { 

2 : value_to_write: uint(bits:9); 

3 : keep soft value Jo_write in [1.. 50]; 

4 ; 

5 : hdLwriter is instance; 

6 : keep hdl_writer.hdl_path() == “channel”; 

7 

8 : unit hdLwriter { 

9 : signal_name: string; 

10 ; keep signal_name == “data”; 

11 : hdljnterface_ref: hdljnterface; ~ this is a reference 

12 : keep hdljnterface_ref == get_enclosing_unit(hdlJnterface); 

13 : 

14 : write() is { 

15 : '(signal_name)’ = hdlJnterface_ref.valueJo_write; 

16 1 }; 

17 : }; 

18 : extend sys { 

19 : hdljf: hdljnterface is instance; 

20 : keep hdljf.hdl_path() == “-/hdljop” 

21 : }; 

I 1 



Analysis of this e program shows that after generation and during run time: 

• sys. hdljnterface has an HDL path of -/hdljop 

• sys.hdl interface. hdLwriter has an HDL path of -/hdljop/channel 

• sys.hdlJnterface.hdLwriter.hdlJnterface_ref is set to sys.hdljnterface 

• Method sys.hdlJnterface.hdLwriter,write() writes the value sys.hdljnterface.value to.write 
HDL signal ~/hdlJop/channel/data 
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5.5 e -Ports 



Verification code modularity can be drastically improved if the interface for a module is 
defined using an abstract port model that makes no assumptions about how it is finally con- 
nected to other modules. The advantage of this approach is that the internal function of the 
module can be implemented using the definition for this abstract port, and module connectivity 
issues can be decided when the module is being instantiated. 

e-Ports provide the port abstraction that facilitates the port modeling approach. e-Ports 
can be used to connect: 

• e modules to e modules 

• e modules to external simulators 

e-Ports have the following properties: 

• can only be declared inside units 

• can be used to pass data or events 

• have one of in, out, orinout directions 

• are accessed by appending “$” to the reference name (i.e. data$ is the value of port data) 

• must be bound to either an external simulated object or another e-port object. Dangling 
e-ports lead to compilation errors unless they are explicitly indicated by binding them to 
empty port. 

Consider a verification module that has an interface consisting of a read p port and write p, 
and a clk_p port that only requires clock transition information. Assume that read_p and writeup 
are each seven bits wide. When using this verification module, read_p, write p, and elk p may 
be connected to another e module, or to signals in an HDL simulator. Then assume that in one 
possible configuration, two verif module instances are connected such that each module’s 
writeup drives the other module’s read p. If the elk event ports of both modules are driven by an 
HDL signal named elk. Then the implementation of this verification module using e-ports is 
shown in the following e program: 



1 : <‘ 

2 : unitverif_module{ 

3 : write_p: out simple_port of uint(bits:7) is instance; 

4 : read_p: in simple_port of uint(bits:7) is instance; 

5 : clk_p: in event_port is instance; 

6 : 

7 : event elk is @clk_p$; 

8 : 

9 : write(value: uint(bits:7)) is { 

10 : write_p$ = value; 

11 ; }: 

12 : read():uint(bits:7) is { 

13 : result = read_p$; 

14 : }; 

15 : }; 

16 : extend sys{ 

17 : vm_1 : verif_module is instance; 

18 : keep vm_1 ,hdl_path() = “-/top”; 
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keep bind(vm_1 .clk_p, external); 
keep vm_1 .dk_p.hdl_path() == “elk”; 
keep vm_1 ,clk_p.edge() == fall; 

vm_2: verif_module is instance; 

keep vm_2.hdl_path() == “-/top”; 

keep bind(vm_2.clk_p, external); 
keep vm_2.clk_p.hdl_path() == “elk”; 
keep vm_2.clk_p.edge() == rise; 

keep bind(vm_1 ,read_p, vm_2.write_p); 
keep bind(vm_1 ,write_p, vm_2.read_p); 

}; 

‘> 

In implementation of verif_module: 

• read_p and write_p ports are implemented using the simple_port construct, each having 
type uint(bits:7). 

• elk p port is implemented using an event_port construct. 

• Port values are accessed by using write_p$, read p$, andclk_p$ for both reading the port 
values and assigning values to ports. 

• Event elk is defined based on event port clk_p. 

In instantiating and connecting the two modules: 

• event port vm_1 ,clk_p is defined to trigger at the falling edge of ~/top/clk since the effec- 
tive name of the elk signal is the combination HDL path for verif_module instance and 
e-port path name. 

• event port vm_1 .elk p is defined to trigger at the rising edge of ~/top/clk. 

• vm 1 .read p is bound to vm 2. write p 

• vm 1 .write p is bound to vm 2.read p 

e-ports provide many options for customization and configuration of the ports, e ports can 
be used to implement buffer ports (queue models), e-ports also provide efficient utilities for 
interfacing to multi-valued signals in the HDL simulator. 



5.6 Packing and Unpacking 

Two important verification activities are injecting stimulus into the device under verification 
and collecting device response. It is often the case that abstract data types travel through device 
ports in a serial bit stream format. An ethernet packet consisting of fields of different lengths 
travels on an ethernet link in a bit serial format. In a verification program, however, verification 
data is usually handled at a higher level of abstraction to improve programming productivity. A 
verification language should therefore provide a utility to translate between an abstract data 
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